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Controller  tnat  binds  processes  to  virtualized  processors. 
Inter-process  communication  mecnamsms  for  synenronizatior. , 
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provided  by  utilization  or  eventopunt  and  sequencer 
primitives.  The  implementation  structure  is  cased  upon 
levels  of  abstraction  and  is  loop  free  to  pprmit  future 
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This  thesis  addresses  the  implementation  of  process 
management  functions  for  the  Secure  Archival  Storage  System 
or  SASS.  This  system  is  designed  to  provide  multilevel 
secure  access  to  information  stored  for  a  network  of 
possibly  dissimilar  nost  computer  systems  and  the  controlled 
sharing  of  data  amongst  authorized  users  of  the  SASS. 
Effective  process  management  is  essential  to  Insure 
efficient  use  and  control  of  the  system. 

Among  the  major  accomplishments  of  tne  work  reported 
here  are  the  inclusion  of  provisions  for  efficient  process 
creation  and  management.  These  functions  are  provided 
through  the  establishment  of  a  system  Traffic  Controller  and 
the  creation  of  a  virtual  interrupt  structure.  An  effective 
mechanism  for  inter-process  communication  and 
synchronization  is  realized  through  an  Event  Manager  that 
makes  use  of  uniquely  identified  segments  supported «*y 
eventcount  and  sequencer  primitives.  A  hardware  controlled 
two  domain  operational  environment  is  created  with  the 

i 

necessary  interfacing  between  domains  provided  by  a  software 
“gate"  mechanism.  Additional  support  is  provided  through 
considerable  work  in  the  area  of  database  initialization  and 
a  technique  for  limited  dynamic  memory  allocation. 
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This  implementation  was  completed  on  the  commercial  AMC 
Am96/4116  MonoBoard  Computer  witn  a  standard  Multibus 
interface . 

A.  BACKGROUND 

The  brief  history  of  digital  computers  has  been 
cnaracteri 2ed  by  rapid  advances  in  nardware  technology  and  a 
continual  increase  in  the  number  and  variety  of  its 
applications.  The  advent  of  the  microprocessor  has  enabled 
virtually  every  level  of  our  society  to  mate  use  of  computer 
resources.  Today's  "desJt  top"  microcomputers,  costing  less 
than  a  thousand  dollars,  have  more  computing  power  than  the 
"giant"  computers  of  the  early  1950's  that  cost  hundreds  of 
times  that  amount. 

These  rapid  advances  In  computer  hardware  technology 
have  reversed  the  economics  of  the  computer  design 
environment.  While  hardware  costs  nave  decreased,  tne 
relative  costs  of  the  software  required  to  effectively 
utilize  tnls  nardware  has  steadily  increased  until  it  now 
dominates  the  overall  cost  of  a  computer  system.  This 
economic  reversal  requires  that  developed  software  be 
logical,  easy  to  read,  relatively  maintenance  free,  and  easy 
to  debug.  Unfortunately,  microcomputer  operating  systems  and 
applications  software  tend  to  be  highly  specialized,  thus 
failing  to  reasonably  exploit  the  potential  of  tne 
microprocessor. 


As  the  usage  of  computers  has  expanded,  expeciaily  In 
the  area  of  sensitive  Information  handling,  the  need  for 
information  security  has  received  greater  recognition.  While 
ad-hoc  attempts  nave  been  made  to  provide  internal  computer 
security  on  larger  systems,  the  problem  of  information 
security  on  microprocessors  has  been  largely  ignored  to 
date. 

In  an  attempt  to  address  the  above  problems,  O'Connell 
and  Richardson  [1]  outlined  a  high  level  design  for  a 
microprocessor  based  secure  operating  system.  The  goal  of 
this  design  was  to  provide  information  security,  distributed 
processing,  multiple  protection  domains,  configuration 
independence,  multiprocessing,  and  multiprogramming.  Since 
all  computer  applications  do  not  require  such  a  broad  and 
general  operating  system,  the  design  provided  for  a  family 
of  operating  systems.  This  allows  a  member  of  the  family  to 
incorporate  only  the  subset  of  family  functions  needed  for 
its  specific  application,  while  providing  for  future 
expansion.  Tne  SASS  is  a  member  of  tnis  operating  system 
family. 

A  brief  nistory  of  prior  wort  done  on  tne  SASS  is  now 
provided.  Parks  [id  J  provided  the  design  for  the  SASS 
Supervisor.  Tne  actual  Implementation  of  tne  Supervisor 
design  has  not  been  addressed  to  date.  The  Initial  design  of 
tne  SASS  Security  Kernel  was  completed  by  Coleman  [3J  .  The 
works  of  O'Connell  and  Richardson  [ij ,  Parks  [2J  ,  and 
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Coleman  [3]  are  available  as  a  single  publication  from  NTIS 
and  DDC  in  a  report  prepared  by  Schell  and  Cox  [21J  .  Further 
refinements  of  tne  Kernel  design  and  partiai  Kernel 
implementation  has  been  accomplished  in  three  additional 
thesis  efforts.  Moore  and  Gary  [4j  provided  the  detailed 
design  and  partial  implementation  of  the  Memory  Manager 
module.  Design  refinements  for  the  Inner  Traffic  Controller 
and  Traffic  Controller  modules  as  well  as  implementation  of 
the  Inner  Traffic  Controller  was  provided  by  Reitz  [5]. 
Wells  [6]  provided  Implementation  of  the  Segment  Manager  and 
Non-Discretionary  Security  modules  as  well  as  partial 
implementation  of  distributed  Memory  Manager  functions. 
These  design  and  implementation  efforts  provided  the  basis 
for  the  worlr  described  here. 

B.  BASIC  CONCEPTS/DEFINITIONS 

This  section  provides  an  overview  of  several  concepts 
essential  to  the  SASS  design.  Readers  familiar  with  SASS  or 
with  secure  operating  system  principles  may  wish  to  sJcip  to 
the  next  section. 

1.  PrPEgSS 

The  notion  of  a  process  has  been  viewed  in  many  ways 
in  computer  science  literature.  Organic*  [7]  defines  a 
process  as  a  set  of  related  procedures  and  data  undergoing 
execution  and  manipulation,  respectively,  by  one  of  possibly 
several  processors  of  a  computer.  Madnics  and  Donovan  [8J 
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view  a  process  as  the  locus  of  points  of  a  processor 
executing  a  collection  of  programs.  Reed  [9J  descrites  a 
process  as  tbe  sequence  of  actions  taJcen  by  some  processor. 


In  otner  words,  it  is  tne  past,  present,  and  future 
"history”  of  the  states  of  the  processor.  In  the  SASS 
design,  a  process  is  viewed  as  a  logical  entity  entirely 
characterized  by  an  address  space  and  an  execution  point.  A 
process'  address  space  consists  of  the  set  of  all  memory 
locations  accessible  by  the  process  during  its  execution. 
This  may  be  viewed  as  a  set  of  procedures  and  data  related 
to  the  process.  The  execution  point  is  defined  by  the  state 
of  the  processor  at  any  given  instant  of  process  execution. 

As  a  logical  entity,  a  process  may  have  logical 
attributes  associated  witn  it,  such  as  a  security  access 
class,  a  unique  identifier,  and  an  execution  state.  This 
notion  of  logical  attributes  should  not  be  confused  witn  tne 
more  typical  notion  of  physical  attributes,  such  as  location 
in  memory,  page  size,  etc.  In  SASS,  a  process  is  given  a 
security  access  class,  at  the  time  of  its  creation,  to 
specify  what  authorization  it  possesses  in  terms  of 
information  access  (to  be  discussed  in  the  next  section).  It 
is  also  given  a  unique  identifier  that  provides  for  its 
identification  by  the  system  and  is  utilized  for  Interaction 
among  processes.  A  process  may  exist  in  one  of  three 
execution  states:  1)  running,  2)  ready,  and  3)  blocked.  In 
order  to  execute,  a  process  must  be  mapped  onto  (bound  to)  a 
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pnysical  processor  in  tne  system.  Such  a  process  is  said  to 
be  in  the  "running"  state.  A  process  that  is  not  mapped  onto 

t 

a  physical  processor,  but  is  otherwise  ready  to  execute,  is 
in  the  "ready"  state.  A  process  in  the  "blocked"  state  is 
waiting  for  some  event  to  occur  in  the  system  and  cannot 
continue  execution  until  the  event  occurs.  At  that  time,  the 
process  is  placed  into  the  ready  state. 

2.  Information  Security 

There  is  an  ever  increasing  demand  for  computer 
systems  that  can  provide  controlled  access  to  the  data  it 
stores.  In  this  thesis,  "information  security"  is  defined  as 
the  process  of  controlling  access  to  information  based  upon 
proper  authorization.  The  critical  need  for  information 
security  should  be  clear.  Banks  and  other  commercial 
enterprises  risk  the  theft  or  loss  of  funds.  Insurance  and 
credit  companies  are  bound  by  law  to  protect  the  private  or 
otherwise  personal  information  they  maintain  on  their 
customers.  Universities  and  scientific  Institutions  must 
prevent  the  unauthorized  use  of  their  often  over-burdened 
systems.  Tne  Department  of  Defense  and  other  government 
agencies  must  face  the  very  real  possibility  that  classified 
information  is  being  compromised  or  that  weapon  systems  are 
being  tampered  with.  In  fact,  security  related  problems  can 
be  found  at  virtually  every  level  of  computer  usage. 

In  tne  past,  attempts  nave  been  made  to  identify  tne 
security  weakness  of  computer  systems  by  trial  and  error  and 
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then  fix  them.  However,  Schell  [lej  has  shown  that  security 
cannot  he  "added  on"  to  an  existing  system  with  any  degree 
of  confidence  that  the  resulting  security  system  is 
impregnable.  Security  must  he  explicitly  designed  into  a 
system  from  first  principles.  The  Jtey  to  achieving  provable 
Information  security  is  realized  in  the  concept  of  the 
"security  fcernel."  Schell  Cl 1 J  provides  a  detailed 
discussion  of  the  use  of  this  concept  in  the  methodical 
design  of  system  security. 

The  security  of  computer  systems  processing 
sensitive  Information  can  be  achieved  by  two  means:  external 
security  controls  and  Internal  security  controls.  In  the 
first  case,  security  is  achieved  by  encapsulating  the 
computer  and  all  its  trusted  users  within  a  single  security 
perimeter  established  by  physical  means  (e.g.,  armed  guards, 
fences,  etc.)  This  means  of  security  is  often  undesirable 
due  to  its  added  cost  of  implementation,  tne  innerent  risk 
of  error-prone  manual  procedures,  and  the  problem  of 
trustworthy  but  error-prone  users.  Also,  since  all  security 
controls  are  external  to  the  computer  system,  the  computer 
is  Incapable  of  securely  handling  data  at  differing  security 
levels  or  users  with  differing  degrees  of  authorization. 
This  restriction  greatly  limits  the  utility  of  modern 
computers.  Internal  security  controls  rely  upon  the  computer 
system  to  internally  distinguish  between  multiple  levels  of 
information  classification  and  user  authorization.  This  is 
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clearly  a  more  desirable  and  flexible  approach  to 
Information  security.  This  does  not  meaa»  however,  tnat 
external  security  is  not  needed.  The  optimal  approach  would 
be  to  utilize  internal  security  controls  to  maintain 
information  security  and  external  security  controls  to 
provide  physical  protection  of  our  system  against  sabotage, 
theft,  or  destruction.  The  primary  concern  of  this  thesis  is 
information  security  and  will  therefore  center  its 
discussion  on  the  achievement  of  information  security 
through  implementation  of  the  security  kernel  concept. 

One  might  argue  that  a  "totally  secure"  computer 
system  is  one  that  allows  no  access  to  its  classified  or 
otherwise  sensitive  information.  Sucn  a  system  would  not  be 
of  much  value  to  its  users.  Therefore,  when  we  say  that  a 
system  provides  information  security,  it  is  only  secure  with 
respect  to  some  specific  external  security  policy 
established  by  laws,  directives,  or  regulations.  There  are 
two  distinct  aspects  of  security  policy:  non-discretionary 
and  discretionary.  Each  user  (subject^  of  the  system  is 
given  a  label  denoting  what  classification  or  level  of 
access  the  user  is  authorized.  Likewise,  all  information  or 
segments  (objects)  within  the  system  are  labelled  with  their 


classification 

or  level  of 

sensitivity. 

The 

non-dlscretlonary 

security  mechanism 

is  responsible 

for 

comparing  the 

au 

thorlzation  of  a 

subject  with 

the 

classification 

of 

an  object  and  determining  what  access 
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any,  should  be  granted.  The  DOD  security  classification 
system  provides  an  example  or  the  non-discretionary  security 
policy  and  is  tne  policy  implemented  in  SASS.  Tne 
discretionary  security  policy  is  a  refinement  of  the 
non-discretionary  policy.  As  sucn,  it  adds  a  nigner  degree 
of  restriction  by  allowin*  a  subject  to  specify  or  restrict 
who  may  nave  access  to  nis  flies.  It  must  be  emphasized  that 
the  discretionary  policy  is  contained  within  the 
non-discretionary  policy  and  in  no  way  undermines  or 
substitutes  for  it.  This  prevents  a  subject  from  granting 
access  that  would  violate  the  non-discretionary  policy.  An 
example  of  discretionary  security  is  provided  by  tne  DOD 
"need  to  know"  policy.  In  SASS,  the  discretionary  policy  is 
implemented  witnin  the  supervisor  [2j  by  means  of  an  Access 
Control  List  (ACL),  There  Is  an  ACL  maintained  for  every 
file  in  tne  system,  wnicn  provides  a  list  of  all  users 
authorized  access  to  that  file.  Every  attempt  by  a  user  to 
access  a  file  is  first  checked  against  tne  ACL  and  tnen 
checked  against  the  non-discretionary  security  policy.  The 
"least”  or  "most  restrictive”  access  found  in  tnese  checks 
is  then  granted  to  the  user. 

The  relationship  between  the  labels  associated  with 
the  subject's  access  class  (sac)  and  tne  object's  access 
class  (oac)  is  defined  by  a  lattice  model  of  secure 
information  flow  [12J  as  follows  ("!"  denotes  "no 
relati onshlp" ) : 
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1.  sac  *  oac,  read  and  write  access  permitted 

2.  sac  >  oac,  read  access  permitted 

3.  sac  <  oac,  write  access  permitted 

4.  sac  f  oac,  no  access  permitted 

In  order  to  understand  bow  these  access  levels  are 
determined,  it  is  necessary  to  gain  an  awareness  or  and 
consideration  for  several  basic  security  properties. 

The  "Simple  Security  Property”  deals  witn  "read" 
access.  It  states  that  a  subject  may  nave  read  access  only 
to  those  object's  whose  classification  is  less  than  or  equal 
to  the  classification  of  the  subject.  This  prevents  a 
subject  from  reading  any  object  possessing  a  classification 
higher  than  his  own. 

The  "Confinement  Property"  (also  Known  as 
""-property" )  governs  "write”  access.  It  states  that  a  user 
may  be  granted  write  access  only  to  those  objects  whose 
classification  is  greater  than  or  equal  to  the 
classification  of  the  subject.  This  prevents  a  user  from 
writing  information  of  a  higher  classification  (e.g.. 
Secret)  into  a  file  of  a  lower  classification  (e.g.. 
Unclassified ) .  It  is  noted  that  while  this  property  allows  a 
user  to  write  into  a  file  possessing  a  classification  higher 
than  his  own,  it  does  not  allow  him  access  to  any  of  the 
data  in  that  file.  The  SASS  design  does  not  allow  a  user  to 
"write  up"  to  higher  classified  files.  Therefore,  in  SASS, 
"sac  <  oac"  denotes  "no  access  permitted." 
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The  "Compatibility  Property"  deals  with  the  creation 
of  objects  in  a  hierarchical  structure.  In  SASS,  objects 
(segments)  are  hierarchically  organized  in  a  tree  structure. 
This  structure  consists  of  nodes  with  a  root  node  from  which 
the  tree  eminates.  The  Compatibility  Property  states  that 
the  classification  of  objects  must  be  non-decreasing  as  we 
move  down  the  hierarchical  structure.  This  prevents  a  parent 
node  from  creatine  a  child  node  of  a  lower  classification. 

Several  prerequisites  must  be  met  in  order  to  Insure 
that  the  security  kernel  design  provides  a  secure 
environment.  Firstly,  every  attempt  to  access  data  must 
invoice  the  Kernel.  In  addition,  the  Kernel  must  be  Isolated 
and  tamperproof.  Finally,  tne  Kernel  design  must  be 
verifiable.  This  implies  that  the  mathematical  model,  upon 
wnich  the  Kernel  is  based,  must  be  proved  secure  and  tnat 
the  Kernel  is  shown  is  to  correctly  implement  this  model. 

3.  Segmentation 

Segmentation  is  a  key  element  of  a  security  Kernel 
based  system.  A  segment  can  be  defined  as  a  logical  grouping 
of  information,  such  as  a  procedure,  file  or  data  area  [8J . 
Therefore,  we  can  redefine  a  process'  address  space  as  the 
collection  of  all  segments  addressable  by  tnat  process. 
Segmentation  is  the  technique  applied  to  effect  management 
of  those  segments  within  an  address  space.  In  a  segmented 
environment,  all  references  within  an  address  space  require 
two  components:  1)  a  segment  specifier  (number)  and  2)  tne 
location  (offset)  within  the  segment. 
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A  segment  may  nave  several  logical  and  pnysical 
attributes  associated  witn  it.  The  logical  attributes  may 
include  the  segment's  classification,  size,  or  permlssable 
access  (read,  write,  or  execute).  Tnese  logical  attributes 
allow  a  segment  to  nicely  fit  the  definition  of  an  object 
within  the  security  kernel  concept,  and  thus  provide  a  means 
for  the  enforcement  of  information  security.  A  segment's 
physical  attributes  include  the  current  location  of  the 
segment,  whether  or  not  the  segment  resides  in  main  memory 
or  secondary  storage,  and  wnere  tne  segment's  attributes  are 
maintained  by  a  segment  descriptor.  The  segment  descriptors 
for  eacn  segment  in  a  process'  address  space  are  contained 
within  a  Descriptor  Segment  (viz.,  the  MMU  Image  in  SASS)  to 
facilitate  the  memory  management  of  that  address  space. 

Segmentation  supports  information  sharing  by 
allowing  a  single  segment  to  exist  in  tne  address  spaces  of 
multiple  processes.  This  allows  us  to  forego  the  maintenance 
of  multiple  copies  of  tne  same  segment  and  eliminates  the 
possibility  of  conflicting  data.  Controlled  access  to  a 
segment  is  also  enforced,  since  eacn  process  can  nave 
different  attributes  (read/write)  specified  in  its  segment 
descriptor.  In  the  implementation  of  SASS,  any  segment  which 


is  shared, 
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has  "read 
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access  by  every 

process 
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is 
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the 

processor  local 
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supporting  each  of  these  processes  ratner  than  in  the  global 
memory.  This  implies  the  maintenance  of  multiple  coples^of 
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some  snared  segments.  It  Is  noted  tnat  tne  problem  of 
"conflicting  data"  is  avoided  since  tills  only  applies  to 
read  only  segments.  This  apparent  waste  of  memory  and  nonuse 
of  existing  snaring  facilities  is  justified  by  a  design 
decision  to  provide  maximum  reduction  of  bus  contention 
among  processors  accessing  global  memory.  This  reduction  in 
bus  contention  is  considered  to  be  of  more  importance  tnan 
the  saving  of  memory  space  provided  by  single  copy  sharing 
of  read  only  segments.  Tnis  decision  is  also  well  supported 
by  the  occurrence  of  decreasing  memory  costs,  which  we  have 


experienced  in  terms  of  high  speed  bus  costs. 

4-.  pmecucfl Jtem&ias 

The  requirement  for  isolating  the  Kernel  from  the 
remainder  of  the  system  is  achieved  by  dividing  tne  address 
space  of  each  process  into  a  set  of  hierarchical  domains  or 
protection  rings  [13J .  O'Connell  and  Richardson  [  1 J  defined 
three  domains  in  the  family  of  secure  operating  systems:  the 
user,  the  supervisor,  and  the  Kernel.  Only  two  domains  are 
actually  necessary  in  the  SASS  design  since  it  does  not 
provide  extended  user  applications.  The  Kernel  resides  in 
the  inner  or  most  privileged  domain  and  has  access  to  all 
segments  in  an  address  space.  System  wide  data  bases  are 
also  maintained  within  the  Kernel  domain  to  Insure  their 
accessibility  is  only  tnrougn  the  Kernel.  The  Supervisor 
exists  in  the  outer  or  least  privileged  domain  where  its 
access  to  data  or  segments  within  an  address  space  is 
restricted . 
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While  protection  domains  may  be  created  through 
either  hardware  or  software  mechanisms,  a  hardware 
Implementation  provides  mucn  greater  efficiency.  Current 
microprocessor  technology  only  provides  for  the 

Implementation  of  two  domains.  This  two  domain  restriction 
does  not  support  O'Connell  and  Richardson's  complete  family 
design,  but  it  is  sufficient  to  allow  hardware 

implementation  of  the  ring  structure  required  by  the  SASS 
subset. 

5.  Abstraction 

Dijlcstra  [14}  has  shown  that  tne  notion  of 
abstraction  can  be  used  to  reduce  tne  complexity  of  a 
problem  by  applying  a  general  solution  to  a  number  of 
specific  cases.  A  structure  of  increasing  levels  of 
abstraction  provides  a  powerful  tool  for  tne  design  of 
complex  systems  and  generally  leads  to  a  better  design  with 
greater  clarity  and  fewer  errors. 

Eacn  level  of  abstraction  creates  a  virtual 

hierarchical  machine  [8]  which  provides  a  set  of  "extended 
instructions"  to  tne  system,  a  virtua'l*s5$cnine  cannot  mane 
calls  to  another  virtual  machine  at  a  higher  level  of 
abstraction  and  in  fact  is  unaware  of  its  existence.  ...  This 
Implies  that  a  level  of  abstraction  is  independent  of  any  ’ 
nigner  levels.  This  independence  provides  for  a  loop-free 
design.  Additionally,  a  higher  level  may  only  maxe  use  of 
tne  resources  of  a  lower  level  by  applying  the  extended 
instruction  set  of  the  lower  level  virtual  machine. 


23 


jsfm:. 


Therefore,  once  a  level  of  abstraction  is  created,  any 
nigner  level  is  only  interested  in  the  extended  instruction 
set  it  provides  and  is  not  concerned  with  the  details  of  its 
implementation.  In  SASS,  once  a  level  of  abstraction  is 
created  for  the  physical  resources  of  the  system,  these 
resources  become  "virtualized"  maxing  the  nigner  levels  of 
the  design  independent  of  tne  physical  configuration  of  the 
system. 


C.  THESIS  STRUCTURE 

This  thesis  describes  the  implementation  of  the  process 
management  functions  for  tne  SASS.  The  design  base  for  this 
implementation  evolved  from  the  secure  family  of  operating 
systems  designed  by  O'Connell  and  Ricnardson  [lj  .  The 
programming  language  utilized  in  this  implementation  was 
PLZ/ASM  assembly  code  [20J . 

Chapter  I  provided  an  introduction  to  the  Secure 
Arcnlval  Storage  System  and  a  discussion  of  tne  basic 
concepts  which  underlie  a  secure  operating  system 
envl ronment . 

Chapter  II  will  provide  a  discussion  of  tne  SASS  design. 
An  overview  of  the  entire  SASS  system  is  presented  along 
with  more  detailed  description  of  tne  modules  comprising 
SASS  and  their  associated  databases. 

Chapter  III  discusses  the  issues  bearing  on  this 
implementation  and  the  refinements  made  to  previous  SASS 
related  worx.  A  discussion  concerning  the  initialization  of 
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the  databases  utilized  by  tne  current  SASS  demonstration  is 
also  presented. 

Chapter  IV  presents  the  implementation  of  process 
management  (viz.,  tne  Traffic  Controller,  Event  Manager, 
Distributed  Memory  Manager,  and  Gate  Keeper  stub  modules).  A 
description  of  design  and  implementation  criteria,  and 
decisions  made  during  implementation  are  also  discussed  in 
this  chapter. 

Chapter  V  provides  the  conclusions  reached,  the  status 
of  tne  researcn,  and  recommendations  relative  to  the 
continuation  and  extension  of  this  worx. 

Tne  appendices  include  tne  PLZ/ASM  code  for  tne  modules 
implemented  and  refined.  The  complete  program  listings  for 
the  Secure  Arcnlval  Storage  System  may  be  obtained  from  a 
report  prepared  by  Schell  and  Cox  122]. 


x 
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II.  S E CUR S  ARCHIVAL  STORAGE  SYSTEM  DESIGN 


This  chapter  provides  an  overview  of  the  SASS  in  its 
current  design  state.  Tne  intent  of  tnis  summary  is 
threefold.  First,  it  is  intended  to  provide  an  overall 
understanding  of  tne  SASS  itself.  Secondly,  it  will  provide 
an  interrelationship  between  the  worit  done  in  this  thesis 
and  previous  woric  performed  on  SASS.  Lastly,  it  provides  a 
current  base  upon  which  further  SASS  development  can  occur. 

A.  BASIC  SASS  OVERVIEW 

The  purpose  of  the  Secure  Archival  Storage  System  is  to 
provide  a  secure  "data  warehouse"  or  information  pool  wnicn 
can  be  accessed  and  shared  by  a  variable  set  of  host 
computer  systems  possessing  differing  security 
classifications.  The  primary  goals  of  the  SASS  design  are  to 
provide  information  security  and  controlled  sharing  of  data 
among  system  users. 

Figure  1  provides  an  example  of  a  possible  SASS  usage. 
Tne  system  is  used  exclusively  for  managing  an  archival 
storage  system  and  does  not  provide  any  programming  services 
to  its  users.  Thus  the  users  of  the  SASS  may  only  create, 
store,  retrieve,  or  modify  files  within  the  SASS.  The  host 
computers  are  hardwired  to  the  system  via  the  I/O  ports  of 
the  Z8001  with  each  connection  having  a  fixed  security 
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classification.  Eacft  ftost  must  nave  a  separate  connection 
for  eacn  security  level  it  wishes  to  vorit  on  (It  is 
important  to  note  tnat  Figure  1  only  represents  tne  logical 
interfacing  of  tne  system.  Specifically,  tne  actual 
connection  vitn  tne  nost  system  must  be  interfaced  with  the 

Kernel  as  the  I/O  instructions  for  tne  port  are  privileged). 

/ 

In  our  example.  Host  #1  can  create  and  modify  only  Top 
Secret  files,  but  it  can  read  files  which  are  Top  Secret, 
Secret,  Confidential,  or  Unclassified.  Likewise,  Host  #2  can 
create  or  modify  secret  files,  using  its  secret  connection 
or  confidential  files,  using  its  confidential  connection. 
Host  #2  cannot  create  or  modify  Top  Secret  or  Unclassified 
files. 

In  order  to  provide  information  security  and  controlled 
sharing  of  files,  the  SASS  operates  in  two  domains:  (l)  tne 
Supervisor  domain  and  (2)  tne  Kernel  domain.  The  SASS 
achieves  this  desired  environment  through  a  distributed 
operating,  system  design  vnicn  consists  of  two  primary 
modules:  the  Supervisor  and  the  Security  Kernel.  Each  host 
system  connected  to  tne  SASS  nas  associated  vitn  it  two 
processes  within  the  SASS  which  perform  the  data  transfer 
and  file  management  on  benalf  of  tnat  nost.  Tne  nost 
computer  communicates  directly  with  its  own  I/O  process  and 
File  Manager  process  vitnin  tne  SASS. 

We  can  use  our  notion  of  abstraction  to  present  a  system 
overview  of  the  SASS.  The  SASS  consists  of  four  primary 
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levels  of  abstraction: 

Level  3-Tne  Host  Computer  Systems 
Level  2-The  Supervisor 
Level  l-The  Security  Kernel 
Level  0-The  SASS  Hardware 

A  pictorial  representation  of  this  abstract  system  overview 
is  presented  in  Figure  2.  This  representation  is  limited  to 
a  dual  nost  system  for  clarity  and  space  restrictions.  Note 
that  the  Gate  Keeper  module  is  in  actuality  the  logical 
boundary  between  levels  one  and  two  and  as  sucn  will  be 
described  separately. 

Level  3,  the  host  computer  systems,  of  SASS  has  already 
been  addressed.  It  should  be  noted  that  the  SASS  design 
mates  no  assumptions  about  the  host  computer  systems. 
Therefore  each  host  may  be  of  a  different  type  or  size 
(i.e.-  micro,  mini,  or  maxi-computer  system).  Furthermore,' 
tne  necessary  physical  security  of  tne  host  systems  and 
their  respective  data  lints  with  the  SASS  is  assumed. 

B.  SUPERVISOR 

Level  2  of  the  SASS  system  is  composed  of  the  Supervisor 
domain.  As  already  stated,  the  SASS  consists  of  two  domains. 
The  actual  implementation  of  these  domains  was  mreatly 
simplified  since  the  78001  microprocessor  provides  two  modes 
of  execution.  The  system  mode,  with  wftich  the  Kernel  was 
implemented,  provides  access  to  all  machine  instructions  and 
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Figure  2.  System  Overview  (Dual  Host) 

3e 


all  segments  within  the  system.  The  normal  mode,  with  which 
the  Supervisor  was  Implemented,  only  provides  access  to  a 
limited  subset  of  machine  instructions  and  segments  within 
the  system.  Therefore,  tne  Supervisor  operates  in  an  outer 
or  less  privileged  domain  than  the  Kernel. 

Tne  purpose  of  the  Supervisor  is  to  manage  the  data  Unit 
between  the  host  computer  systems  and  the  SASS  by  means  of 
Input/Output  control,  and  to  create  and  manage  tne  file 
hierarchy  of  each  host  within  the  SASS.  These  functions  are 
accomplished  via  an  Input/Output  (I/O)  process  and  a  File 
Manager  (TM)  process  within  the  Supervisor.  A  separate  FM 
and  I/O  process  are  created  and  dedicated  to  eacn  host  at 
the  time  of  system  initialization. 

1.  File  Manager  Process 

The  FM  process  directs  the  interaction  between  tne 
host  computer  systems  and  the  SASS.  It  interprets  all 
commands  received  from  the  Host  computer  and  performs  the 
necessary  action  upon  them  through  appropriate  calls  to  the 


Kernel.  The 
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management 

of  the 
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enforcement  of  the  discretionary  security  policy. 

The  virtual  file  system  of  the  Host  is  viewed  as  a 
nlerarcny  of  files  which  are  implemented  in  a  tree 
structure.  The  five  basic  actions  which  may  be  initiated 
upon  a  file  at  this  level  are:  1)  to  create  a  file,  2)  to 
delete  a  file,  3)  to  read  a  file,  4)  to  store  a  file,  and  5) 
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to  modify  a  file.  The  F M  process  utilizes  a  FM  Known  Segment 
Taoie  (FM_KST)  as  tne  primary  database  to  aid  in  tnis 
management . 


Tne  FM  process  maintains  an  Access  Control  list 
(ACL)  through  wnich  it  enforces  tne  discretionary  security 
in  SASS.  Tne  FM  process  initializes  an  ACL  for  every  file  in 
its  Host's  file  system.  The  ACL  is  merely  a  list  of  all 
users  tnat  are  autnorized  to  access  tnat  file.  Tne  ACL  is 
checked  upon  every  attempt  to  access  a  file  to  determine  its 
autnori zation .  Tne  user  (nost  computer)  directs  tne  FM 
process  as  to  what  entries  or  deletions  snould  be  made  in 
tne  ACL,  and  as  sucn,  specifies  wno  ne  wisnes  to  nave  access 
to  his  file.  As  noted  earlier,  discretionary  security  is  a 
refinement  to  the  Non-Discretionary  Security  Policy  and 
therefore  can  only  be  utilized  to  add  furtner  access 
restrictions  to  those  provided  by  the  Non-Discretionary 
Security."  This  prevents  a  user  from  granting  access  to  a 
file  to  someone  who  otnerwise  would  not  be  autnorized 
access. 

2.  Input/Output  Process 

The  I/O  process  is  responsible  for  managing  the 
input  and  output  of  all  data  between  tne  nost  computer 
systems  and  tne  SASS.  The  I/O  process  is  subservient  to  the 
FM  process  and  receives  ail  of  its  commands  from  it.  Data  is 
transferred  between  tne  SASS  and  Host  Computer  systems  in 
fixed  size  "packets”.  These  packets  are  broken  up  into  tnree 


basic  types:  1)  a  synchronization  packet,  2)  a  command 
packet,  and  3)  a  data  paclcet.  In  order  to  insure  reliable 
transmission  and  receipt  of  packets  between  the  Host 
computer  and  the  SASS,  there  must  exist  a  protocol  between 
them.  Parks  [2]  provides  a  more  detailed  description  of 
these  packets,  and  a  possible  multi-packet  protocol. 

C.  GATE  KEEPER 

The  primary  objective  of  the  gate  keeper  is  to  isolate 
the  Kernel  and  make  it  tamperproof.  This  *oal  is 
accomplished  by  reason  of  a  software  ring  crossing  mecnanism 
provided  by  the  *ate  keeper.  In  terms  of  SASS,  this  notion 
of  "ring-crossing”  is  merely  the  transition  from  tne 
Supervisor  domain  to  the  Kernel  domain.  As  noted  earlier, 
the  gate  keeper  establishes  the  logical  boundary  between  the 
Supervisor  and  the  Kernel,  and  as  a  matter  of  course,  it 
provides  a  single  software  entry  point  (enforced  by 
hardware)  into  the  Kernel.  Therefore,  any  call  to  the  Kernel 
must  first  pass  through  the  gate  keeper. 

The  <rate  keeper  acts  as  a  trap  handler.  Cnee  it  is 
invoked  by  a  user  (Supervisor)  process,  the  hardware  preempt 
interrupts  are  masked,  and  the  user  process'  registers  and 
stack  pointer  are  saved  (within  tne  kernel  domain).  It  then 
takes  the  argument  list  provided  by  the  caller  and  validates 
these  passed  parameters  to  insure  tneir  correctness.  To  aid 
in  the  validation  of  these  parameters,  the  eate  keeper 
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utilizes  tne  Parameter  Tattle  as  a  database.  Tne  Parameter 


table  contains  all  of  tne  permitted  functions  provided  by 
tne  Kernel.  These  relate  directly  to  the  extended 
instruction  set  (viz..  Supervisor  calls)  provided  by  the 
Kernel  (these  extended  instructions  will  be  described  in  the 
next  section).  If  an  invalid  call  is  encountered  by  the  gate 
Keeper,  an  error  code  Is  returned,  and  the  Kernel  is  not 
invoiced.  If  a  valid  call  is  encountered  by  tne  gate  Keeper, 
the  arguments  and  control  are  passed  to  the  appropriate 
Kernel  module. 

Once  the  Kernel  has  completed  its  action  on  the  user 
request,  it  passes  tne  necessary  parameters  and  control  bacK 
to  the  gate  Keeper.  At  this  point,  the  gate  Keeper 
determines  if  any  software  virtual  preempt  interrupts  nave 
occurred.  If  they  nave,  then  the  virtual  preempt  handler  is 
InvoKed  vice  the  Kernel  bein*  exited  (virtual  interrupt 
structure  is  discussed  in  chapter  III).  Correspondingly,  if 
a  software  virtual  preempt  has  not  occurred,  then  the  return 
arguments  are  passed  to  tne  user  process.  Tne  user  process' 
registers  and  stacK  pointer  (viz.,  its  execution  point)  are 
restored  and  control  returned  to  tne  Supervisor  domain.  A 
detailed  description  of  the  Gate  Keeper  interface  and 
implementation  is  provided  in  chapter  IV. 


34 


VT 


D.  DISTRIBUTED  KERNEL 

Level  1  of  our  abstract  view  of  SASS  consists  of  two 
components:  the  distributed  Kernel  and  tne  non-distributed 
Kernel.  Tnese  two  elements  comprise  tne  Security  Kernel  of 
the  SASS.  The  Security  Kernel  has  two  primary  objectives:  1) 
tne  management  of  the  system's  nardware  resources,  and  2) 
the  enforcement  of  the  non-discretlonary  security  policy.  It 
executes  in  tne  most  privileged  domain  (viz.,  tne  system 
mode  of  the  Z8001)  and  has  access  to  all  machine 
instructions.  The  following  section  will  provide  a  brief 
description  of  the  distributed  Kernel,  its  components,  and 
the  extended  instruction  set  it  provides.  A  discussion  of 
the  non-distributed  Kernel  will  be  giver  in  the  next 
section. 

The  distributed  Kernel  consists  of  those  Kernel  modules 
whose  segments  are  contained  (distributed)  in  the  address 
space  of  every  user  (Supervisor)  process.  Thus,  in  effect, 
the  distributed  Kernel  is  shared  by  all  user  processes  in 
the  SASS.  Tne  distributed  Kernel  is  composed  of  the  Segment 
Manager,  the  Event  Manager,  the  Non-Discretionary  Security 
Module,  tne  Traffic  Controller,  tne  Inner  Traffic 
Controller,  and  the  Distributed  Memory  Manager  Module.  The 
Segment  Manager  and  the  Event  Manager  are  the  only  "user 
visible"  modules  in  the  distributed  Kernel.  In  other  words, 
the  set  of  extended  instructions  available  to  user  processes 
invoice  either  the  Segment  Manager  or  the  Event  Manager. 
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1.  Segment  Manager 

The  objective  of  the  Segment  Manager  Is  the 
management  of  a  process'  segmented  virtual  storage.  The 
Segment  Manager  Is  invoked  by  calls  from  the  Supervisor 
domain  via  the  gate  Keeper.  Calls  to  tne  Segment  Manager  are 
made  by  means  of  six  extended  instructions  provided  by  the 
segment  manager.  These  extended  instructions  (viz.,  entry 
points)  are:  1)  CREATE_SEGMENT ,  2)  DELETE_SEGMENT ,  3) 
MAKE_KNOWN,  4)  TERMINATE,  5)  SM_SWAP_IN,  and  6)  SM_SWAF_OUT. 
The  extended  instructions  CREATE_SEGMENT  and  DELETE_SEGMENT 
add  and  remove  segments  from  the  SASS.  MAKE_KN0W N  and 
TERMINATE  add  and  remove  segments  from  the  address  space  of 
a  process.  Finally,  SM_SWAP_IN  and  SM_SWAP_OUT  move  segments 
from  secondary  storage  to  main  storage  and  vice  versa. 

The  primary  database  utilized  by  the  Segment  Manager 
is  the  Known  Segment  Table  (KST) .  A  representation  cf  tne 
structure  of  tne  KST  is  provided  in  figure  3.  The  KST  is  a 
process  local  database  that  contains  an  entry  for  every 
segment  in  the  address  space  of  that  process.  The  KST  is 
Indexed  by  segment  number  with  each  record  of  the  KST 
containing  descriptive  information  for  a  particular  segment. 
The  KST  provides  a  mapping  mechanism  by  which  the  segment 
number  of  a  particular  segment  can  be  converted  into  a 
unique  nandle  for  use  by  the  Memory  Manager.  The  Memory 
Manager  will  be  discussed  in  the  next  section. 
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The  purpose  of  me  Event  Manager  is  me  management 


of  event  data  vhicn  is  associated  with  interprocess 
communications  within  tne  SASS.  This  event  data  is 
implemented  by  means  of  eventcounts  (a  synchronization 
primitive  discussed  by  Reed  [15J ) .  Tne  Event  Manager  is 
invoked,  via  the  Gate  Keeper,  by  user  processes  residing  in 
the  Supervisor  domain.  Tnere  are  two  eventcounts  associated 
with  every  segment  existing  in  the  Supervisor  domain.  These 
eventcounts  (viz..  Instance  l  and  Instance  2)  are  maintained 
in  a  database  residing  in  the  Memory  Manager.  The  Event 
Manager  provides  its  management  functions  tnrougn  its 
extended  instruction  set  READ,  TICKET,  AD7ANCE,  and  AWAIT, 
and  in  conjunction  with  tne  extended  instructions  TC_ADVANCE 
and  TC_AWAIT  provided  by  the  Traffic  Controller  (to  te 
discussed  next).  These  extended  instructions  are  based  on 
the  mechanism  of  eventcounts  and  sequencers  [15],  The  Event 
Manager  verifies  the  access  permission  of  every  interprocess 
communication  request  through  the  Non-Discretionary  Security 
Module.  The  extended  instruction  READ  provides  tne  current 
value  of  the  eventcount  requested  by  the  caller.  TICKET 
provides  a  complete  time  ordering  of  possibly  concurrent 
events  through  the  mechanism  of  sequencers.  The  Event 
Manager  will  be  discussed  in  more  detail  in  chapter  IV. 


Non-Discretionary  Security  Module 


The  purpose  of  the  Non-Discretionary  Security  Module 


(NDS)  is  the  enforcement  of  me  non-discretionary  security 
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policy  of  tee  SASS.  Welle  tne  current  implementation  of  SASS 
represents  tne  Department  of  Defense  security  policy,  any 
security  policy  which  may  be  represented  tnrougn  a  lattice 
structure  112]  may  also  be  implemented.  Tne  NDS  is  invoiced 
via  its  extended  instruction  set:  CLASS_EQ  and  CIASS_GE.  Tne 
NDS  is  passed  two  classifications  which  it  compares  and  then 
analyzes  their  relationship.  CLASS_EQ  will  return  a  true 
value  to  the  calling  procedure  only  if  the  two 
classifications  passed  were  equal.  The  CLASS_GE  instruction 
will  return  true  if  a  given  classification  is  analyzed  to  be 
either  greater  man  or  equal  to  another  given 
classification.  The  NDS  does  not  utilize  a  data  base  as  it 
worlcs  only  with  tne  parameters  it  is  passed. 

4.  Traffic  Controller 


i 

The  tasic  of  processor  scheduling  is  performed  by  the 
traffic  controller.  Saltzer  tie J  defines  traffic  controller 
as  tne  processor  multiplexing  and  control  communication 
section  of  an  operating  system.  Tne  current  SASS  design 
utilizes  Reed's  [9J  notion  of  a  two  level  traffic 
controller,  consisting  of:  1)  a  Traffic  Controller  (TC)  and 
2)  an  Inner  Traffic  Controller  (ITC). 

The  primary  function  of  the  Traffic  Controller  is 
the  scheduling  (binding)  of  user  processes  onto  virtual 
processors.  A  virtual  processor  (VP)  is  an  abstract  data 
structure  that  simulates  a  physical  processor  through  the 
preservation  of  an  executing  process'  attributes  (viz.,  tne 
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execution  point  and  address  space).  Multiple  VP's  may  exist 
for  every  physical  processor  in  the  system.  Two  VP's  are 
permanently  bound  to  Kernel  processes  (viz..  Memory  Manager 
and  Idle)  and  as  sucn  are  not  in  contention  for  process 
scheduling.  These  processes  and  tneir  corresponding  virtual 
processors  are  invisible  to  the  TC.  The  remaining  virtual 
processors  are  either  idle  or  are  temporarily  bound  to  user 
processes  as  scheduled  by  the  TC .  The  database  utilized  by 
the  TC  in  process  scheduling  is  the  Active  Process  Table 
(APT).  Figure  4  provides  the  structure  of  the  APT. 

The  APT  is  a  system-wide  Kernel  database  containing 
an  entry  for  every  user  process  in  the  system.  Since  the 
current  SASS  design  does  not  provide  for  dynamic  process 
creation/deletion,  a  user  process  is  active  for  the  life  of 
tne  system.  Therefore,  tne  size  of  tne  APT  is  fixed  at  the 
time  of  system  veneration.  The  APT  is  logically  composed  of 
tnree  parts:  1)  an  APT  header,  2)  tne  main  body  of  tne  APT, 
and  3)  a  VP  table.  The  APT  header  includes:  1)  a  Lock  to 
provide  for  a  mutual  exclusion  mecnanism,  2)  a  Running  List 
indexed  by  VP  ID  to  identify  the  current  process  runninv  on 
each  VP,  3)  a  Ready  List,  which  points  to  the  linked  list  of 
processes  which  are  ready  for  scheduling,  and  4)  a  blocked 
List,  which  points  to  the  linked  list  of  processes  which  are 
in  the  blocked  state  awaiting  the  occurrence  of  some  event. 

A  design  decision  was  made  to  incorporate  a  single 
list  of  blocked  processes  instead  of  the  more  traditional 
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Figure  4.  Active  Process  Table  (APT) 


notion  of  separate  lists  per  eventcount  because  of  its 
simplicity  and  its  ease  of  implementation.  Tnis  decision 
does  not  appreciably  affect  system  performance  or  efficiency 
as  the  "blocked”  list  will  never  be  very  long.  The  VP  table 
is  indexed  by  logical  CPU  number  and  specifies  tne  number  of 
VP's  associated  witn  the  logical  CPU  and  its  first  VP  in  the 
Running  list.  The  logical  CPU  number,  obtained  during  system 
initialization,  provides  a  simple  means  of  uniquely 
identifying  each  pnysical  CPU  in  the  system.  The  main  body 
of  the  APT  contains  the  user  process  data  required  for  its 
efficient  control  and  scheduling.  NEXT_AP  provides  the 
linked  list  threading  mechanism  for  process  entries.  The  DBR 
entry  is  a  handle  identifying  the  process'  Descriptor 
Segment  which  is  employed  in  process  switching  and  memory 
management.  The  ACCESS__CLASS  entry  provides  every  process 
with  a  security  label  that  is  utilized  by  the  Event  Manager 
and  the  Segment  Manager  in  the  enforcement  of  the 
Non-Discreti onary  Security  Policy.  The  PRIORITY  and  STATE 
entries  are  the  primary  data  used  by  the  Traffic  Controller 
to  effect  process  scheduling.  AFFINITY  identifies  the 
logical  CPU  which  is  associated  with  the  process.  VP  ID  is 
utilized  to  identify  the  virtual  processor  that  is  currently 
bound  to  the  process.  Finally,  the  EVENTCOUNT  entries  are 
utilized  by  the  TC  to  manage  processes  which  are  blocked  and 
awaiting  the  occurrence  of  some  event.  HANDLE  identifies  the 
segment  associated  with  tne  event,  INSTANCE  specifies  the 
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event*  and  COUNT  determines  which  occurrence  of  the  event  is 


needed . 


The  Traffic  Controller  determines  the  scheduling 


order  by  process  priority.  Every  process  is  assigned  a 
priority  at  the  time  of  its  creation.  Once  scheduled,  a 
process  will  run  on  its  VP  until  it  eitner  blocks  itself  or 
it  is  preempted  by  a  higher  priority  process.  To  insure  that 
the  TC  will  always  have  a  process  available  for  scheduling, 
there  logically  exists  an  "idle"  process  for  every  VP 
visible  to  the  TC.  These  "idle”  processes  exist  at  the 
lowest  process  priority  and,  consequently,  are  scheduled 
only  if  there  exists  no  useful  wortc  to  be  performed. 

The  Traffic  Controller  is  invoked  by  the  occurrence 
of  a  virtual  preempt  interrupt  or  through  its  extended 
Instruction  set:  ADVANCE,  AWAIT,  PROCESS_CLASS ,  and 
GET_DBP._NU!“!BER .  ADVANCE  and  AWAIT  are  used  to  implement  the 
IPC  mechanism  envofced  by  the  Supervisor.  PROCESS_CLASS  and 
GET_DBR_NUttBER  are  called  by  the  Segment  manager  to 
ascertain  the  security  label  and  DBR  handle,  respectively, 
of  a  named  process.  A  more  derailed  discussion  of  the  TC  is 
provided  in  chapters  III  and  IV. 


The  Inner  Traffic  Controller  is  the  second  part  of 
our  two-level  traffic  controller.  Basically,  the  ITC 
performs  two  functions.  It  multiplexes  virtual  processors 
onto  the  actual  physical  processors,  and  it  provides  the 
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primitives  for  wnicn  inter-VP  communication  witnin  tne 
Kernel  is  implemented.  A  design  cnoice  was  made  to  provide 
eacfl  physical  processor  in  tne  system  vitn  a  small  fixed  set 
of  virtual  processors.  Two  of  tnese  VP's  are  permanently 
bound  to  tne  Kernel  processes.  Tne  Memory  Manager  is  tound 
to  the  highest  priority  VP.  Conversely,  tne  Idle  Process  is 
bound  to  tne  lowest  priority  VP  and,  as  a  result,  will  only 
be  scneduled  if  there  exists  no  useful  work  for  tne  CFU  to 
perform.  Tne  primary  database  utilized  by  tne  ITC  is  tne 
Virtual  Processor  Table  (VPT).  Figure  5  illustrates  the  VPT. 

The  VPT  is  a  system  wide  Kernel  database  containing 
entries  for  every  CPU  in  the  system.  The  VPT  is  logically 
composed  of  four  parts:  1)  a  header,  2)  a  VP  data  table,  3) 
a  message  table,  and  4)  an  external  VP  list.  The  header 
includes  a  LOCK  (spin  lock)  tnat  provides  a  mutual  exclusion 
mechanism  for  table  access,  a  PUNNING  LIST  (indexed  by 
logical  CPU  #)  tnat  identifies  tne  VP  currently  running  on 
the  corresponding  physical  CPU,  a  READ!  LIST  (indexed  by 
logical  CPU  #)  wnicn  points  to  tne  linked  list  of  VP's  wnicn 
are  in  the  ready"  state  and  awaiting  scheduling  on  that 
CPU,  and  a  FP EE  LIST  wnicn  points  to  tne  linked  list  of 
unused  entries  in  the  message  table.  Tne  VP  data  table 
contains  tne  descriptive  data  required  by  tne  ITC  to 
effectively  manage  the  virtual  processors.  The  DBR  entry 
points  witnin  tne  MMU  Image  to  tne  descriptor  segment  for 
the  process  currently  running  on  tne  VP.  PRI  (Priority), 
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STATE,  IDLE_FLAG,  and  PREEMPT  are  tne  primary  data  used  by 
the  ITC  for  VP  scheduling.  PREEMPT  indicates  whether  cr  not 
a  virtual  preempt  is  pending  for  tne  VP.  Tne  IDLE_FLAG  is 
set  whenever  the  TC  has  bound  an  "idle"  process  to  the  VP. 
Normally,  a  VP  with  tne  IDLE_FLAG  set  will  not  be  scneduled 
by  the  ITC  as  it  has  no  useful  wortc  to  perform.  In  fact, 
sucn  a  VP  will  only  be  scneduled  if  tne  PREEMPT  flag  is  set. 
This  scheduling  will  allow  the  VP  to  be  given  (bound)  to 
another  process.  PHYSICAL  PROCESSOR  contains  an  entry  from 
the  Processor  Data  Segment  (PRDS)  that  Identifies  the 
physical  processor  tnat  the  VP  is  executing  on.  E}T_V?_ID  is 
the  identifier  by  which  the  VP  is  Jrnown  by  the  Traffic 
Controller.  A  design  choice  was  made  to  nave  tne  EXT_VP_ID 
equate  to  an  offset  into  the  External  VP  List.  The  External 
vp  list  specifies  tne  actual  VP  ID  (viz.,  VPT  entry  number) 
for  each  external  VP  identifier.  This  precluded  the 
necessity  for  run  time  calculation  of  offsets  for  the 
EXT_TrP_ID .  NEXT  READT  VP  provides  the  threading  mechanism 
for  tne  "Ready"  linked  list,  and  MSG  LIST  points  to  tne 
first  entry  in  the  Message  Table  containing  a  message  for 
tnat  VP.  Tne  Message  Table  provides  storage  for  the  messages 
generated  in  the  course  of  Inter-Virtual  Processor 
communications.  MSG  contains  tne  actual  communication  being 
passed,  while  SENDER  Identifies  the  VP  which  initiated  the 
communication.  NEXT_MSG  provides  a  threading  mechanism  for 
multiple  messages  pending  for  a  single  VP. 
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The  ITC  is  invoiced  by  means  of  its  extended 
instruction  set:  WAIT,  SIGNAL,  SWAP_VDBR,  IDLE,  SET_PP.EEMPT , 
and  RUNNING_VP.  WAIT  and  SIGNAL  are  tne  primitives  employed 
in  implementing  the  Inter-VP  communication.  SWAP_VDBR,  IDLE, 
SET_PRE£MPT,  and  RUNNING_VP  are  ail  invoiced  by  tne  Traffic 
Controller.  SWAP_VDBR  provides  the  means  by  whicn  a  user 
process  is  temporarily  bound  to  a  virtual  processor.  IDLE 
binds  the  "Idle”  process  to  a  VP  (the  implication  of  this 
instruction  will  be  discussed  later).  SET_PREEMPT  provides 
the  means  of  indicating  that  a  virtual  preempt  interrupt  is 
pending  on  a  VP  (specified  by  the  TC )  by  setting  the  PREEMPT 
flag  for  that  VP  in  the  VPT.  RUNNING_VP  provides  tne  TC  with 
the  external  VP  IE  of  the  virtual  processor  currently 
running  on  the  physical  processor. 

6.  Distributed  Memory  Manager 

The  Distributed  Memory  Manager  provides  an  interface 
structure  between  the  Segment  Manager  and  the  Memory  Manager 
Process.  Tnis  interfacing  is  necessitated  by  tne  fact  that 
the  Memory  Manager  Process  does  not  reside  in  the 
Distributed  Kernel  and  consequently  is  not  included  in  tne 
user  process'  address  space.  The  primary  functions  performed 
in  this  module  are  tne  establishment  of  Inter-VP 
Communication  between  the  VP  bound  to  its  user  process  and 
tne  V?  permanently  bound  to  the  Memory  Manager  Process,  tne 
manipulation  of  event  data,  and  the  dynamic  allocation  of 
available  memory.  Tne  Distributed  Memory  Manager  Module  is 
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invoked  fey  the  Segment  Manager  tnrougn  its  extended 
instruction  set:  MM_CREATE_ENTRY ,  MM_EELETE_ENTRI f 
MM_ACTI7ATE,  MM_DEACTI7ATE,  MM_SWA?_IN,  and  MM_SWAP_  OUT . 
Tnese  extended  instructions  are  utilized  on  a  one  to  one 
basis  fey  tne  extended  Instruction  set  of  tfte  Segment  Manager 
(e.g . *  SM_SVAP_IN  utilizes  (calls)  MM_SWAP_IN).  wells  [6J 
provides  a  more  detailed  description  of  tnis  portion  of  tne 
Eistrifeuted  Memory  Manager  and  tne  extended  instruction  set 
associated  with  it. 

The  Distributed  Memory  Manager  is  also  invoked 
tnrougn  its  remaining  extended  Instructions: 
MM_READ_EVENTCOUNT,  MM_TICKET,  MM_AD7ANCE,  and  MM_ALLOCATE. 
These  Distributed  Memory  Manager  functions  will  be  discussed 
in  detail  in  chapter  17. 

E.  NON -DISTRIBUTED  KERNEL 

The  Non-Distributed  Kernel  is  the  second  element 
residing  in  Level  l  of  our  abstract  system  view  of  tne  SASS . 
Tne  sole  component  of  the  Non-Distributed  Kernel  is  the 
Memory  Manager  Process. 

1.  Memory  Manager  Process 

Tne  primary  purpose  of  tne  Memory  Manager  Process  is 
the  management  of  all  memory  resources  within  the  SASS. 
Tnese  include  tne  local  and  global  main  memories,  as  well  as 
the  hard-disk  based  secondary  storage.  A  dedicated  Memory 
Manager  Process  exists  for  every  CPU  in  tne  system.  Eacn  CPU 


48 


possesses  a  local  memory  where  process  local  segments  and 
snared,  non-writeable  segments  are  stored.  Tnere  is  also  a 
Global  memory,  to  which  every  CPD  has  access,  where  the 
snared,  writeable  segments  are  stored.  It  is  necessary  to 
store  these  snared,  writeable  segments  in  the  global  memory 
to  ensure  tnat  a  current  copy  exists  for  every  access. 

The  Memory  Manager  Process  is  tasted  by  other 
processes  within  the  Kernel  domain  (via  Signal  and  Wait)  to 
perform  memory  management  functions.  These  basic  functions 
include  the  allocation/deallocation  of  local  and  global 
memory  and  of  secondary  storage,  and  the  transfer  of 
segments  between  tne  local  and  global  memory  and  between 
secondary  storage  and  the  main  memories.  The  extended 
instruction  set  provided  by  tne  Memory  Manager  Process 
includes:  CREATE, ENTRY ,  DELETE_ENTRY,  ACTIVATE ,  DEACTIVATE, 
SWAP_IN,  and  SWAP_OUT.  These  instructions  correspond  one  to 
one  with  those  of  the  Distributed  Memory  Manager  Module.  The 
system  wide  data  bases  utilized  by  all  Memory  Manager 
Processes  are  the  Global  Active  Segment  Table  (G_AST ) ,  the 
Alias  Table,  the  Dlslr  Bit  Map,  and  the  Global  Memory  Eit 
Map.  The  processor  local  databases  used  by  each  Memory 
Manager  Process  are  tne  Local  Active  Segment  Table  ( L_AST ) , 
and  the  Local  Memory  Bit  Map.  Gary  and  Moore  l4j  provide  a 
detailed  description  of  tne  Memory  Manager,  its  extended 
instruction  set,  and  its  databases. 
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A  summary  of  tne  extended  instruction  set  created  by 
the  components  of  tne  Security  Kernel  is  provided  by  Figure 
6.  One  mignt  question  tne  prudence  of  omitting 
?EYS_PFEEMPT_HANDLER  and  7IF.T_P3SEMPT_HAND1.£R  (viz.,  the 
nandier  routines  for  physical  and  virtual  interrupts'  from 
the  extended  instruction  set  as  both  of  tnese  interrupts  may 
be  raised  (viz.,  initiated)  from  within  the  Kernel.  A 
decision  was  made  to  not  classify  these  handlers  as 
"extended  instructions”  since  tney  are  only  executed  as  the 
result  of  a  physical  or  virtual  interrupt  and  as  such  cannot 
be  directly  invoiced  (viz.,  "called"}  by  any  module  in  the 
system.  A  summary  of  the  databases  utilized  by  Kernel 
modules  is  presented  in  Figure  ?. 

F.  SYSTEM  HARDWARE 

Level  0  of  the  SASS  consists  of  the  system  hardware. 
This  hardware  includes:  1)  tne  CPU,  2)  the  local  memory,  3) 
the  Global  memory,  4)  the  secondary  storage  (viz.  nard 
distc),  and  5)  tne  I/O  ports  connecting  tne  Host  computer 
systems  to  the  SASS.  Since  the  SASS  design  allows  for  a 
multiprocessor  environment,  there  may  exist  multiple  CPU's 
and  local  memories.  The  target  machine  selected  for  the 
initial  implementation  of  tne  system  is  tne  Zilog  Z8001 
microprocessor  ll7j .  The  Z8001  is  a  general  purpose  lb-bit, 
register  oriented  machine  that  has  sixteen  16-bit  general 
purpose  registers.  It  can  directly  address  8M  bytes  of 
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memory,  extensible  to  46M  bytes.  Tne  Z6001  arcnitecture 
supports  memory  segmentation  ana  two-domain  operations.  The 
memory  segmentation  capability  is  provided  externally  by  tne 
Zilog  Z8f?10  Memory  Management  Unit  (MMU).  Tne  Z8f It',  MMU  [l£j 
provides  management  of  tne  Z8001  addressable  memory,  dynamic 
s°gment  relocation,  and  memory  protection.  Memory  segments 
are  variable  In  site  from  256  bytes  to  64£  bytes  and  are 
identified  by  a  set  of  64  Segment  Descriptor  Registers, 
wnicn  supply  tne  information  needed  to  map  logical  memory 
addresses  to  pnyscal  memory  addresses.  Each  of  the  64 
Descriptor  Registers  contains  a  16-bit  case  address  field, 
an  e-bit  limit  field,  and  an  6-bit  attribute  field. 
Unfortunately,  tne  Z8001  nardware  was  not  available  for  use 
during  system  development.  Therefore,  ail  worfc  to  date  nas 
been  completed  tnrougn  utilization  of  tne  Z8002 
non-segmented  version  of  the  Z8000  microprocessor  family 
[17 J  .  Tne  actual  nardware  used  in  this  implementation  is  tne 
Advanced  Micro  Computers  Amy6/4llb  MonoRoard  Computer  liyj 
containing  tne  AmZ8002  sixteen  bit  non-segmented 
microprocessor.  This  computer  provides  32K  bytes  of  on-board 
RAM,  8 it  bytes  of  PROM/ROM  space,  two  RS232  serial  I/O  ports, 
24  parallel  I/O  lines,  and  a  standard  INTEL  Multibus 
interface.  Tne  general  structure  of  tne  design  nas  teen 
preserved  by  simulation  of  the  segmentation  hardware  in 
software.  Tnis  software  MMU  Image  (see  Figure  8)  is  created 
as  a  database  within  the  Inner  Traffic  Controller. 
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Tne  MMU  Image  is  a  processor-local  database  indexed  by 
D£R_No.  Eacn  QBR_No  represents  one  record  within  the 
Image.  Each  record  is  an  exact  software  copy  of  tne  Segment 
Descriptor  Register  set  in  tne  nardware  MMU.  Each  element  of 
tftis  software  Image  is  in  tne  same  form  utilized  by  tne 
special  I/O  instructions  to  load  the  nardware  MMU .  Eacr.  DBR 
record  is  indexed  cy  segment  number  (Segment_No) .  Eacn 
Segment_No  entry  is  composed  of  tnree  fields:  Base_Addr, 
Limit,  and  Attributes.  Base_Addr  is  a  16-bit  field  wnicn 
contains  t&e  base  address  of  tne  segment  in  pfcyscal  memory. 
Limit  is  an  e-bit  field  tnat  specifies  tne  number  of 
contiguous  blocks  of  memory  occupied  by  tne  segment. 
Attributes  is  an  8-blt  field  representing  tne  eigni  flags 
which  specify  tne  segment's  attributes  (e.g.,  "read", 
"execute",  "write",  etc.). 


G .  SUMMARY 

An  extended  overview  of  the  current  SASS  design  nas  been 
presented  in  this  cnapter.  The  four  major  levels  of 
abstraction  comprising  the  SASS  system  have  been  identified 
and  tne  major  components  of  eacn  level  nave  been  discussed. 
The  extended  instruction  set  provided  by  tne  SAbS  kernel  was 
also  defined.  With  this  background,  tne  actual  details  cf 


tnis  Implementation  will  be  described  in  chapters  Ill  and 


Issues  bearing  on  tne  implementation  of  process 
management  and  refinements  made  to  existing  modules  are 
presented  in  tnis  chapter.  Process  management  for  tne  SASS 
was  provided  through  tne  implementation  of  the  Traffic 
Controller  Module,  the  Event  Manager  Module,  tne  Distributed 
Memory  Manager  Module,  and  a  Gate  Keeper  Stub  (system  trap'. 
Additionally,  since  a  demonstration/testbed  was  integral  to 
tne  testing  ard  verification  of  tne  implementation,  it  was 
necessary  to  complete  other  supportive  tasits.  These 
supportive  tasirs  included  limited  Kernel  database 
initialization,  revised  preempt  interrupt  handling 
mecnanisms.  Idle  process  definition  and  structure,  and 
additional  refinements  to  existing  modules. 

A.  DATABASE  INITIALIZATION 

Previous  wors  on  SASS  has  relied  on  statically  built 
databases,  which  proved  to  be  sufficient  for  demonstration 
of  a  single  processor,  single  nost  supported  system.  In  the 
current  demonstration,  multiple  hosts  are  simulated,  and  tne 
Kernel  data  structures  have  been  refined  to  represent  a 
multiprocessor  environment.  Since  a  multiprocessor  system 
was  unavailable  at  tne  time  of  tnis  demonstration,  several 
"runs"  were  made  and  traced,  using  different  logical  CPU 
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numbers,  to  snow  tne  correctness  of  this  structure.  Due  to 
tftis  multiprocessor  representation  and  simulation  of 
multiple  nosts,  tne  use  of  statically  built  Kernel  databases 

was  no  longer  convenient.  Therefore,  it  became  necessary  to 
provide  initialization  routines  for  tne  dynamic  creation  of 
those  Kernel  databases  required  for  this  implementation. 
While  it  wa«  not  tne  intent  of  tnls  effort  to  implement 
system  initialization,  care  was  taKen  in  the  writing  of 
these  initializing  routines  so  that  they  might  be  utilized 
in  tne  system  intiaiization  implementation  with,  nopefuilv, 
minimal  refinement.  Database  initialization  was  restricted 
to  tnose  databases  existing  in  tne  Inner  Traffic  Controller 
and  the  Traffic  Controller.  Limited  elements  of  the  Known 
Segment  Table  (KST )  and  Global  Active  Segment  Table  ( G_  AST ) 
were  also  created  for  demonstration  purposes. 

1 .  Inner  Traffic  Controller  Initialization 

A  "Bootstrap  Loader"  Module,  vhlcn  logically  exists 
at  a  nigner  level  of  abstraction  witnin  tne  Kernel,  was 
created  to  initialize  the  databases  of  the  Inner  Traffic 
Controller.  Tnis  initialization  includes  tne  creation  of:  l) 
the  Processor  Data  Segment  (PHDS),  2)  an  MMU  vap,  3)  Kernel 
domain  staca:  segments  for  Kernel  processes,  4)  allocation 
and  updating  of  MMU  entries  for  Kernel  processes,  and  5) 
Virtual  Processor  Table  (VPT)  entries. 

Tne  PRDS  was  loaded  with  constant  values  that 
specify  tne  pnysicai  CPU  ID,  logical  CPU  ID,  and  number  of 
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VP's  allocated  to  the  CPU.  A  design  decision  was  made  to 
allocate  logical  CPU  ID's  in  increments  of  two  (beginning 
witn  zero)  so  tnat  taey  could  be  used  tc  directly  access 
lists  indexed  by  CPU  number.  Tne  MMU  map,  constructed  as  a 
"byte"  map,  was  created  to  specify  allocated  and  free  MmU 
Image  entries. 

A  separate  procedure,  CREATS_STACK ,  was  created  to 
establisn  tne  initial  Kernel  domain  stacJc  conditions  for 
Kernel  processes.  A  discussion  and  diagram  of  tnese  initial 
stack  conditions  is  presented  in  tne  next  section. 
ALLOCATE_MMU  checks  tne  MMU  Map  and  allocates  tne  next 
availabe  MMU  entry  to  tne  process  being  created.  Tne  PRDS  is 
inserted  in  tne  allocated  MMU  entry  and  tne  DBR  number  is 
returned  to  tne  calling  procedure.  Tne  DPR  number  (nandie) 
is  merely  tne  offset  of  tne  DBA  in  tne  MMU  Image.  Since  tne 
ITC  deals  witn  an  address  ratner  tnan  a  nandie,  a  procedure, 
GET_DBR_ADDR ,  was  created  to  convert  tnis  offset  into  a 
pnysical  address.  UPDAT5_MMU_IMAGE  is  tne  procedure  wnicn 
creates  or  modifies  MMU  Image  entries.  UPEATE_MMU_IMAGE 
accepts  as  arguments  the  DBR  number,  segment  number,  segment 
attributes,  and  segment  limits.  To  facilitate  process 
switching  and  control,  various  process  segments  must  possess 
tne  same  segment  number  system  wide.  This  is  accomplished 
luring  initialization  tnrougn  tne  use  of  tne 
UPDATE_MMU_lMAGE  procedure.  In  tne  ITC,  these  segments 
Include  tne  PPDS  (segment  number  zero)  and  tne  Kernel  stack 
segment  (segment  number  one). 
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Tne  final  tasic  required  in  ITC  intiaiization  is  tne 
creation  of  the  VPT.  The  VPT  neader  is  initialized  with  the 
"running"  and  "ready"  lists  pointers  set  to  a  'nil'  state, 
and  the  "free"  list  pointer  set  to  the  first  entry  in  tne 
message  table.  Virtual  Processor  entries  are  inserted  in  the 
main  body  of  the  VPT  by  the  U?DATE_VP_TA.8LE  procedure. 
Entries  are  first  made  for  the  VP's  permanently  bound  to  the 
Memory  Manager  and  Idle  processes.  The  VP  bound  to  the  MM 
process  is  eiven  a  priority  of  2  (highest),  and  the  VP  bound 
to  the  Idle  process  is  given  a  priority  of  Z  (lowest).  The 
External  VP  ID  for  both  of  these  VP's  is  set  to  "nil"  as 
they  are  not  visible  to  the  Traffic  Controller.  The 
remaining  VP's  allocated  to  tne  CPU  (viz.,  TC  visible  VP's) 
are  then  entered  in  the  VPT  with  a  priority  of  1 
(intermediate),  and  their  "idle"  and  "preempt"  flags  are 
set.  The  preempt  flag  is  set  for  these  TC  visible  VP's  to 
insure  proper  scheduling  by  tne  Traffic  Controller.  Tne  EBP. 
for  these  remaining  VP's  is  initialized  with  the  Idle 
process  DBR.  A  discussion  of  "idle"  processes  ana  VP's  will 
be  provided  later  in  this  chapter.  The  External  VP  ID  for 
eacn  TC  visible  VP  is  merely  tne  offset  of  tne  next 
available  entry  in  tne  EXTERNAL  VP  LIST.  This  External  VP  ID 
is  entered  in  tne  VPT,  and  tne  corresponding  V?  ID  (viz., 
VPT  Entry  ft)  is  entered  in  the  EXTERNAL  VP  LIST. 

Once  tnese  VPT  entries  nave  been  made,  it  is 
necessary  to  set  tne  state  of  each  VP  to  "ready"  and  thread 


tnem  ( by  priority)  into  tne  appropriate  ready  list.  A  VPT 
threading  mechanism  was  provided  by  Reitz  [5j  in  procedure 
MAKE_READY.  However,  it  was  desired  to  nave  a  more  general 
threading  mechanism  that  could  be  used  for  other  lists. 
Procedure  1IST_INS£RT  was  created  to  provide  this  general 
threading  mechanism.  LIST_INSERT  is  logically  a  "library" 
function  tnat  exists  at  tne  lowest  level  of  abstraction  in 
tne  Kernel.  This  function  threads  an  object  into  a  list 
(specified  by  the  caller)  in  order  of  priority,  and  tnen 
sets  its  state  as  specified  by  the  calling  parameters. 

Once  tne  "Bootstrap  Loader"  nas  completed  ITC 
initialization,  it  passes  control  to  tne  ITC  GET’fORK 
procedure  to  begin  VP  scheduling. 

2.  Traffic  Controller  Initialization 

The  initialization  routines  for  tne  TC  include 
TC_INIT,  .  CPEATS_PROCESS,  and  CREATS_KST.  These  routines  are 
called  from  tne  Memory  Manager  process.  Tne  MM  process  was 
chosen  to  initiate  these  routines  as  it  is  bound  to  tne 
highest  priority  VP  and  will  begin  running  immediately  after 
the  Inner  Traffic  Controller  is  initialized.  Procedure 
MM_ALLOCATE  was  written  to  allocate  memory  space  for  lata 
structures  during  initialization  (viz.,  Kernel  stacks,  user 
stacks,  and  AST's).  Memory  space  is  allocated  in  blocks  of 
liiii  (hex)  bytes.  MM_ALLOCATE  is  merely  a  stub  of  the  memory 
allocating  procedure  designed  by  Moore  and  Gary  [4j  . 


It  was  necessary  to  pass  long  lists  of  arguments  to 
tfte  TC  for  Initialization  purposes.  To  ail  in  this  passing 
of  parameters,  a  data  structure  template  was  used.  This 
template  was  created  by  declaring  tne  parameters  as  a  data 
structure  in  botn  the  sending  and  receiving  procedures,  and 
then  imaging  this  structure  at  absolute  address  zero.  The 
process'  stack  pointer  was  then  decremented  ty  tne  size  of 
the  parameter  data  structure,  and  the  parameters  were  loaded 
into  this  data  structure  indexed  by  tne  stack  pointer.  Tnis 
template  made  it  very  easy  to  send  and  receive  long  argument 
lists  using  the  process'  stack  segment. 

TC_INIT  initializes  tne  APT  header  and  virtual 
interrupt  vector  (discussed  later).  Each  element  of  tne 
running  list  is  marked  "idle”,  the  ready  and  blocked  lists 
are  set  to  "nil",  and  the  number  of  VP's  and  first  VP  for 
each  CPU  are  entered  in  the  VP  table.  The  address  of  the 
virtual  preempt  handler  is  then  passed  to  the  ITC  procedure 
CREATE_INT_VEC  for  insertion  in  tne  virtual  interrupt 
vector. 

CREATE_PROCESS  intiaiizes  user  processes  and  creates 
entries  in  the  APT.  ALLOCATE_MMU  is  called  to  acquire  a  DPR 
number,  and  an  APT  entry  is  created  with  tne  process 
descriptors  (viz.,  parameters).  Tne  process  is  then  declared 
"ready”  and  threaded  into  the  approciate  ready  list  by 
calling  the  threading  function,  LIST_INSERT.  A  user  stack  is 
allocated  and  UPDATE_MMU_II*AGE  is  called  to  include  tne  user 


staclc  in  the  MMU  as  segment  number  tnree.  The  user  staclc 
contains  no  information  or  user  process  initialization 
parameters  (viz.,  execution  point  and  address  space)  as  all 
processes  are  initialized  and  begin  execution  from  the 
Kernel  domain.  Next,  a  Kernel  domain  staclc  is  allocated  and 
included  in  the  MMU  Image.  A  design  decision  was  made  to 
initialize  tne  Kernel  stacics  for  user  processes  with  tne 
same  structure  as  the  Kernel  process'  stacics.  The  rationale 
for  this  decision  is  presented  in  tne  next  section.  As  a 
result  of  this  decision,  it  became  possible  to  use  the 
CREATE_STACK  procedure  in  building  Kernel  domain  stacics  for 
both  Kernel  and  user  prosesses.  CREATE_STACK  was  therefore 
used  as  a  library  function  and  placed  in  tne  li Drary  module 
with  LIST-INSERT. 

Finally,  a  Known  Segment  Table  ( KST )  stub  is  created 
to  provide  a  means  of  demonstrating  the  mechanism  provided 
by  tne  eventcounts  and  sequencers  for  interprocess 
communication  ( IPC )  and  mutual  exclusion.  Space  for  tne 
process'  KST  is  created  by  calling  MM_ALLOCATE.  The  KST  is 
then  included  in  tne  process'  address  space,  as  segment 
number  two,  by  U?DaTE_MMU_IMAGE.  initial  entries  are  made  in 
the  Known  Segment  Table  by  procedure  CREATE_KST.  CR£ATE_KST 
maxes  an  entry  in  the  KST  for  the  "root"  and  marics  tne 
remaining  KST  entries  as  "available."  Tne  Unique_ID  portion 
of  the  root's  handle  (viz.,  upper  two  words)  is  initialized 
as  -1  (for  convenience)  and  tne  G_AST  entry  number  portion 
of  the  handle  (viz.,  lowest  word)  is  initialized  with  zero. 
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3.  Additional  Ini tlalizatlon  Requirements 

As  already  mentioned,  tne  Memory  Manager  Process 
prepares  tne  arguments  utilized  Dy  TC_INIT,  CREATE_PF.CC£SS  . 
and  C?JEATE_£ST  for  TC  initialization  and  user  process 
creation.  Additionally,  tne  MM  process  creates  a  Global 
Active  Segment  Table  (G_AST)  stub  utilized  for  demonstration 
of  event  data  management.  The  G_AST  stub  is  declared  in  a 
separate  module  (viz.,  the  DEMO_DATABASE  Module)  with  tne 
format  prescribed  by  Moore  and  Gary  [4j  .  However,  the  only 
fields  initialized  and  utilized  by  this  implementation  are 
UNIQUE_ID,  SEQUENCER,  INSTANCE  1,  and  INSTANCE  d .  The 
eventcounts  and  sequencer  fields  are  initialized  as  zero 
whenever  an  entry  is  created  in  the  G_AST .  The  UNIQUE_II  is 
created  Just  to  support  this  demonstration  ana  does  not 
reflect  the  segment's  unique  identifier  as  specified  by 
Moore  and  Gary  [4j  .  In  tnls  demonstration,  TJNIQUE_ID  is 
built  with  the  parameters  passed  to  MM_ACTIVATE.  The  first 
word  in  UNIQTJE_ID  is  tne  G_AST  entry  number  of  tne  segment's 
parent,  and  the  second  word  is  the  segment's  entry  number 
into  tne  alias  table.  The  UNIQUE_ID  together  with  tne  offset 
of  the  segment's  entry  in  the  G_AST  comprise  the  segment 
HANDLE  maintained  in  tne  KST.  Tne  first  entry  in  tne  G_AST 
is  reserved  for  the  root,  and  is  initialized  with  an 
Unique_ID  of  minus  one  (-1).  It  snoull  be  noted  tnat  any 
call  to  MM_ACTI7ATE  for  a  segment  already  possessing  an 
entry  in  tne  G_AST  will  not  effect  any  changes  to  that 
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entry.  This  is  to  insure  tnat  a  single  G_AST  entry  exists 
for  every  segment  as  specified  by  Moore  and  Gary  |.4j  . 


2.  PREEMPT  INTERRUPTS 

Various  refinements  were  made  in  the  handling  of  both 
physical  (hardware)  ana  virtual  (software)  preempt 
interrupts.  A  hardware  preempt  is  a  non-vectored  interrupt 
that  invokes  the  virtual  processor  scheduling  mecnanism 
(viz.,  ITC  GETVORK).  A  virtual  preempt  is  a  software 
vectored  interrupt  that  invokes  tne  user  process  scheduling 
mechanism  (viz.,  TC_GETWORK).  This  implementation  provides 
tne  notion  of  a  virtual  interrupt  tnat  closely  mirrors  tne 
behavior  of  a  hardware  interrupt.  In  particular,  there  are 
similar  constructs  for  initialization  of  a  handler, 
invocation  of  a  handler,  masking  of  interrupts,  and  return 


from  a  handler.  As  with  most  hardware  interrupts,  a  virtual 
interrupt  can  occur  only  at  tne  comnletion  of  execution  for 
an  "instruction,”  where  each  kernel  entry  and  exit  for  a 
process  delimit  a  single  "virtual  instruction . 


rsical  Preempt  Handler 


The  pnysical  preempt  handler  resides  in  tne  virtual 
processor  manager  (viz..  Inner  Traffic  Controller).  The 
functions  it  perform  are:  l)  save  tne  execution  point,  Z) 
invoke  ITC  GETWORK,  3)  check  for  virtual  preempt  interrupts, 
4)  restore  the  execution  point,  and  5)  return  control  via 
the  IRET  instruction.  Reitz  [5J  included  the  hardware 


preempt  nandler  in  ITC  GETWORK  by  es taoiishing  two  entry 
points  and  two  exit  points,  one  for  a  regular  call  to 
GETWORK  and  another  ror  the  preempt  interrupt.  He  had  a 
separate  procedure,  TEST_PREEMPT ,  that  was  used  to  cneci  for 
the  occurrence  of  virtual  preempt  interrupts.  This  structure 
worics  nicely,  but  it  requires  some  means  of  determining  how 
GETWORK  was  invoiced  so  that  the  proper  exiting  mechanism  is 
used.  This  was  resolved  by  incorporating  a  preempt  interrupt 
flag  in  the  status  register  blocic  of  every  process'  Kernel 
domain  stacic  segment.  A  design  decision  was  made  to 
restructure  the  hardware  preempt  handler  into  a  single  and 
separate  procedure,  PHTS_PREEMPT_HANDL£R .  Tnis  allowed  ITC 
GETWORK  to  have  a  single  entry  and  exit  point,  and  it  lid 
away  witn  the  necessity  of  maintaining  a  preempt  interrupt 
flag  in  the  process  stacKs.  PKIS_PREEMPT_HANELER  was 
constructed  from  the  preempt  handling  code  in  GETWORK  and 
procedure  TEST_PREEMFT .  TEST_PRSE!*PT  was  deleted  from  the 
ITC  as  its  functions  were  performed  by  FHVS_PFEEMPT-HANDLER . 

A  further  refinement  was  made  to  the  hardware 
preempt  handler  dealing  with  the  method  by  which  tne  virtual 
preempt  handler  was  invoiced.  Reitz  IhJ  invoiced  the  virtual 
preempt  nandler  from  TEST_PRESMPT  oy  means  of  the  "call" 
Instruction.  Since  the  virtual  preempt  nandler  logically 
exists  at  a  higner  level  of  abstraction  than  the  I^C,  this 
invocation  violated  our  notion  of  only  allowing  "calls"  to 
lower  or  equal  abstraction  levels.  However,  tnis  deviation 


was  necessitated  by  the  absence  of  a  virtual  interrupt 
structure.  Tnis  problem  was  alleviated  by  creating  a  virtual 
interrupt  vector  in  tfle  ITC  tnat  is  used  in  tne  sane  way  as 
tne  nardware  interrupt  vector.  Tne  virtual  preempt  was  given 
a  virtual  interrupt  number  (zero).  Tne  virtual  interrupt 
nandier  is  tnen  invoiced  by  means  of  a  "jump"  tnrougn  tne 
virtual  interrupt  vector  for  virtual  interrupt  nunDer  0. 
Tnis  invocation  occurs  in  tne  same  manner  tnat  tne  Handlers 
for  nardware  interrupts  are  invoker.  The  virtual  interrupt 
vector  is  created  ty  procedure  CREaTE_INT_V£.C . 
CREATE_INT_7EC  accepts  as  arguments  a  virtual  interrupt 
number  and  tne  address  of  tne  interrupt  nanaler.  Tne 
creation  of  tne  virtual  preempt  entry  in  tne  virtual 
interrupt  vector  is  accomplished  at  the  time  of  the  Traffic 
Controller  initialization  oy  TC_INIT. 

2.  Virtual  Preempt  Handler 

Tne  virtual  oreempt  handler  (VIRT_PR2EMPT_HANLIER ) 
resides  in  the  user  process  manager  (viz.,  the  Traffic 
Controller).  The  functions  performed  by  VIRT_FREEMPT_HANBLER 
are:  1^  determine  tne  VP  ID  of  the  virtual  processor  beinsr 
nreempted ,  2)  invoice  tne  nrocess  scheduling  mecnanism  (viz., 
TC_GSTXORK ) ,  and  3)  return  control  via  a  virtual  interrupt 
return.  Tne  correct  VP  ID  is  obtained  by  calling  RUNNING_VP 
in  the  ITC.  Tne  Active  Process  Table  is  then  locked,  and  tne 
state  of  tne  process  running  on  tnat  vp  is  changed  to 
"ready."  At  this  time,  process  scnedulin*  is  effected  by 
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calling  TC_G£TWORK.  Once  process  scneduling  is  completed, 
tde  APT  is  unlocked  and  control  is  returned  via  a  virtual 
interrupt  return.  Tnis  virtual  interrupt  return  is  merely  a 
jump  to  tde  PREEMPT^PET  label  in  tne  nardware  preempt 
nandler  (Tnis  jump  emulates  tne  action  of  tne  1RET 
instruction  for  a  nardware  interrupt  return).  Tnis  label  is 
tne  point  at  wnicft  the  virtual  preempt  interrupts  are 
unmasired . 

All  Kernel  processes  are  initialized  to  appear  as 
tnougn  tney  are  returning  from  a  nardware  preempt  interrupt. 
All  user  processes  initially  appear  to  be  returning  from  a 
virtual  preempt  interrupt.  Tnerefore,  tne  initial  conditions 
of  a  orocess'  Kernel  domain  staclc  is  largely  influenced  oy 
tne  stacir  manipulation  of  tne  preempt  nandiers.  Figure  a 
illustrates  the  initial  Kernel  domain  stac*  structure  for 
all  system  processes. 

The  initial  Kernel  Flag  Control  Word  (FCW)  value  is 
"5000",  indicating  non-segmented  node,  system  mode  of 
operation,  ncn-vectored  interrupts  masked,  and  vectored 
interrupts  enabled.  The  Current  Stacir  Pointer  value  is  set 
to  tne  first  entry  in  tde  stact  (viz.,  SP).  Tne  IRET  Frare 
is  tne  portion  of  tne  Kernel  stacir  affected  by  tne  IRET 
instruction.  The  first  element.  Interrupt  ID  (set  ro  "FFFF") 
is  merely  popped  off  of  tne  stacir  and  discarded.  Tne  next 
element.  Initial  FCW,  is  popped  and  placed  in  tne  system 
Flag  Control  Word.  Initial  FCW  is  set  to  for  Kernel 
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processes  and  "1800"  (indicating  normal  mode  with  ail 
interrupts  enabled)  for  user  processes.  Tfte  final  element  of 
tne  IRET  frame,  Initial  IC  is  popped  off  of  tne  stacjr  and 
placed  in  the  program  counter  (PC^  resister.  Tnis  value  is 
initialized  as  tne  entry  address  of  tne  process  in  auesticn. 

The  "register"  entries  on  the  stac*  represent  the 
initial  register  contents  for  tne  process  at  tne  beginning 
of  its  execution.  Since  tne  Kernel  processes  (viz.,  and 
Idle)  do  not  require  any  specific  initial  register  states, 
their  entries  reflect  the  register  contents  at  the  time  of 
stact  creation.  Initial  register  conditions  are  used  to 
provide  initial  "parameters"  required  by  the  user  processes. 
This  will  depend  largely  upon  tne  parameter  passing 
conventions  of  tne  implementation  language.  The  means  for 
register  initialization  was  provided  through  CREATE_PRCCESS > 
however,  the  only  initial  register  condition  used  for  the 
user  processes  in  this  demonstration  was  register  #13. 
Register  #13  was  used  to  pass  tne  user  ID/Host  number  of  tne 
process  created.  This  value  is  utilized  by  the  user  process 
in  activating  the  segment  used  for  inter-process 
communication  between  a  Host's  File  manager  and  I/O 
processes.  Another  logical  parameter  passed  to  the  user 
processes  is  the  root  segment  number.  This  did  not  require  a 
register  for  passing  in  tne  demonstration  as  it  is  Known  to 
be  the  first  entry  in  the  KST  for  all  processes.  The  N_S_P 
entry  on  tne  stack  represents  tne  initial  value  of  the 


normal  stack  pointer.  For  user  processes,  tnis  value  is 
obtained  wnen  tne  Supervisor  domain  stack  for  tnat  process 
is  created.  For  Kernel  processes,  this  value  is  set  to 
"FFFF”  since  tney  execute  solely  in  tne  Kernel  domain  and 
nave  no  Superivsor  domain  stack.  Tne  Preempt  Return  Point 
specifies  tne  address  vnere  control  will  be  passed  once  tne 
process'  is  scheduled  and  tne  "return"  from  ITC  GETWORK 
is  executed.  For  Kernel  processes,  tnis  is  tne  point  witnin 
tne  hardware  preempt  handler  where  the  virtual  processor 
table  is  unlocked.  For  user  processes,  tnis  is  tne  point 
within  tne  virtual  preempt  handler  where  tne  Active  Process 
Table  is  unlocked. 

It  is  important  to  note  tnat  if  tne  APT  was  not 
unlocked  when  a  user  process  be?an  its  initial  execution, 
the  system  would  become  deadlocked  and  no  further  process 
scheduling  could  occur.  It  should  be  further  noted  that  tne 
initial  stack  conditions  for  user  processes  do  not  reflect  a 
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C.  IDLE  PROCESSES 

In  tne  SASS  design,  mere  logically  exists  a  Kernel 
domain  "idle"  process  for  every  physical  processor  in  the 
system  and  a  Supervisor  domain  "idle"  process  for  every  "TC 
visible"  virtual  processor  in  tne  system.  These  processes 
are  necessary  to  insure  that  both  tne  VP  scheduler  (viz., 


ITC  GETWORK )  and  the 

process  scheduler 

( TC_GETWORK ' 

will 

always 

nave  some 

object 

to  schedule,  nence  preciudi 

rg  any 

CPU  or 

VP  from  ever 

having 

an  undefined 

execution 

point . 

Since 

the  Kernel 

domain 

Idle  process 

performs  no 

useful 

work,  1 

t  could  be  included 

within  the  ITC 

by  means 

of  an 

infinite  looping  mechanism.  Tne  Kernel  Idle  process  was 
maintained  separately,  however,  as  it  is  hoped  that  future 
work  on  SASS  will  provide  tnis  Idle  process  witn  some 
constructive  purpose  (e.g.,  performing  maintenance 
diagnostics ) . 
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The  Supervisor  domain  Idle  processes  (nereafter  referred 
to  as  TC  Idle  processes)  are  scheduled  (bound)  on  VP's  when 
there  are  no  user  processes  awaiting  scheduling.  Since  a  TC 
Idle  process  performs  no  user  constructive  worfc,  we  do  not 
want  any  VP  executing  a  TC  Idle  process  to  be  bcurd  to  a 
physical  processor.  In  other  words,  a  VP  bound  to  a  TC  Idle 
process  assumes  the  lowest  system  priority  (represented  by 
the  "idle  flag").  Therefore,  any  such  VP  will  have  its  idle 
flag  set  and  will  not  be  scheduled  unless  it  receives  a 


virtual  preempt  interrupt.  Such  an  interrupt  will  allow  the 
v?  to  be  rescneduied  cy  tne  Traffic  Controller.  It  snouid  be 
obvious,  at  this  point,  that  a  TC  Idle  process  will  never 
actually  begin  execution  on  a  real  processor.  Tnls  lrnoviedge 
allowed  a  design  decision  to  be  made  to  only  simulate  the 
existence  of  TC  Idle  processes.  At  tne  TC  level,  tnls  was 
accomplished  by  a  constant  value,  IDLS_PROC,  that  was  used 
as  a  process  ID  in  tne  APT  running  list,  tnus  precluding  tne 
necessity  of  any  ’’idle"  entries  in  the  APT.  At  the  ITC 
level,  any  VP  marked  "idle"  (viz.,  tne  idle  flag  set)  was 
given  the  DER  number  (viz.,  address  space)  of  the  Kernel 
Idle  process  solely  to  provide  tne  use  of  a  Kernel  domain 
stacir  for  rescheduling  of  the  VP. 

D.  ADDITIONAL  KERNEL  REFINEMENTS 

In  addition  to  those  already  discussed,  several  other 


refinements  to  existing  Kernel  modules  were  effected  in  tnls 


implementation.  One  of  tnese  refinements  deals  with  tr.e  way 
virtual  processors  are  identified  by  tne  Traffic  Controller. 
In  tr.e  current  irplementati on ,  all  TC  visible  virtual 
processors  are  given  an  External  VP  ID  which  corresponds  to 
its  entry  number  in  ar.  External  VP  List.  This  required  a 
modification  to  the  ITC  procedure  PUNNIhG_V?.  The  benefits 
derived  from  this  refinement  included  the  ability  to 
directl*'  access  the  External  VP  ID  in  tne  Virtual  Processor 
Table  vice  the  requirement  of  a  run  time  division  to  compute 
its  value  and  the  anility  to  use  the  External  VP  ID  as  an 
index  into  tne  TC  running  list. 

Refinements  were  also  made  to  the  existing  Memory 
Manager,  File  manager,  ana  10  process  stuts  used  for 
demonstration  purposes.  Tnese  refinements  were  largely 
associated  with  tne  eventcount  and  sequencer  mecnanisms 
utilized  in  this  implementation.  The  current  status  of  these 
processes  is  provided  in  a  report  ty  Scneil  and  Cox  [22J . 

The  remaining  refinements  deal  largely  with  the  MMU 
Image.  In  Moore  and  Gary's  [4j  design,  tne  MMU  Image  was 
managed  by  the  Memory  Manager  process.  This  was  largely 
because  the  MMU  Image  is  a  processor  local  database  ana 
would  seem  well  suited  for  management  cy  the  non-di stri buted 
Kernel.  In  fact,  tne  MMU  Image  Is  utilized  mainly  cy  tne  ITC 
for  the  multiplexing  of  process  address  spaces.  Therefore, 
in  the  current  design,  tne  MM’J  T  ->s  are  maintained  by  the 
Inner  Traffic  Controller,  however,  the  MMU  header  proposed 
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by  Poore  ana  Gary  (viz.,  the  BL0CAS_TJS  ED  ana 
PAXI MUP_A7AI LABLE^ELOCKS  fields)  was  retained  in  tne  Memory 
Panager  as  it  is  used  strictly  in  tne  management  of  a 
process'  virtual  core  and  is  not  associated  witn  tne 
nardware  PMU . 

In  wells'  design  [6] ,  the  Traffic  Controller  used  tne 
linear  ordering  of  tne  DER  entries  in  tne  PMU  Image  as  tne 
DER  nandle  (viz.,  1,2,3...).  Tnis  required  a  run  time 
division  operation  to  compute  tne  DER  number,  and  a  run  time 
multiplication  operation,  by  PM_GET_DBR_VALUE ,  tc  recompute 
tne  DER  address  for  use  by  tne  ITC.  In  tne  current  design, 
the  offset  of  tne  DER  entry  in  tne  PMU  Image  (obtained  at 
tne  time  of  PPU  allocation)  is  used  as  tne  DER  nandle  in  tne 
Traffic  Controller.  Furthermore,  SWAF_VDBR  was  refined  to 
accept  a  DER  handle  ratner  tnar.  a  DER  address  to  preclude 
tne  necessity  of  tne  Traffic  Controller  having  to  deal  witn 
PPU  addresses.  DER  addresses  are  computed  oniv  within  the 
ITC  (viz.,  by  procedure  GET_DE?_ADDR )  by  adding  tne  value  of 
tne  DER  handle  to  the  base  address  of  the  PPU  Image.  Since 
DER  addresses  are  now  used  solely  within  tne  ITC.  procedure 
mp_get_DER_V AIDE  was  no  longer  needed  and  was  deleted  from 
tne  Pemcry  Panager. 

E.  SUMMARY 

Tne  primary  issues  addressed  in  tnis  thesis  effort  nave 
been  presented  in  tnis  cnapter.  Aside  from  tne  process 
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management  functions,  tms  description  included  a  mecnanlsm 
for  limited  Kernel  dataoase  initialization,  a  revised 
preempt  interrupt  nandling  mecnanlsm,  tne  creation  of  a 
virtual  interrupt  structure,  a  definition  of  "idle" 
processes  and  tneir  structure,  and  a  discussion  of  tne  minor 
refinements  effected  in  existing  SASS  modules.  A  detailed 
description  of  tne  implementation  of  process  management 
functions  for  tne  SASS  is  presented  in  tne  next  cnapter. 


* 
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PROCESS  MANAGEMENT  IMPLEMENTATI CM 


Tne  implementation  of  process  management  functions  and  a 
gate  keeper  stub  (system  trap)  is  presented  in  tnls  chapter. 
Tne  implementation  is  discussed  in  terms  of  tne  Event 
Manager,  Traffic  Controller,  Distributed  Memory  Manager, 
User  Gate,  and  Kernel  Gate  Keeper  modules.  A  tiock  diagram 
depicting  tne  structure  and  interreiationsnips  of  these 
modules  is  presented  in  figure  10.  Support  in  developing  the 
Z9000  machine  code  for  tnis  implementation  was  provided  by  a 
Zllog  MCZ  Developmental  System  operating  under  the  F10 
operating  system.  The  Deveiopmenta l  System  provided  disk 
file  management  for  a  dual  drive,  hard  sectored  floppy  disk, 
a  line  oriented  text  editor,  a  PLZ/ASM  assembler,  a  linker 
and  a  loader  that  created  an  executable  image  of  earn  Z80fcO 
load  module.  An  upload/download  capability  with  the 
Am96/4116  MonoJBoard  computer  was  also  provided.  This 
capability,  along  with  tne  general  interfacing  of  the 
Am96/4116  into  the  SASS  system,  was  accomplished  in  a 
concurrent  tnesis  endeavor  by  Gary  Balter.  Baker's  work 
relating  to  hardware  initialization  in  SASS,  will  be 
published  upon  completion  of  his  thesis  work  in  June  1981. 
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Figure  10.  Implementation  Module  Structure 


A.  EVENT  MANAGER  MODULE  _ 

The  eventcount  and  sequencer  primitives  1.15!  ,  which  are 
system-wide  objects,  collectively  comprise  the  event  data  of 
SASS.  As  mentioned  earlier,  this  event  data  is  tied  directly 
to  system  segments  and  is  stored  in  the  Glohal  Active 
Segment  Table.  There  are  two  eventcounts  and  one  sequencer 
for  every  segment  in  the  system.  These  objects  are 
identified  to  tne  Kernel  in  user  calls  by  specification  of  a 
segment  number.  Once  this  segment  number  is  identified  by 
tne  Kernel,  tne  segment's  handle  can  be  obtained  from  tne 
process'  Known  Segment  Table.  The  segment  handle  identifies 
tne  particular  entry  in  tne  G_AST  containing  tne  event  data 
desi red . 

Tne  Event  Manager  module  manages  tne  event  data  within 
the  system  and  provides  tne  mecnanlsm  for  interprocess 
communication  between  user  processes.  The  Event  Manager 
consists  of  sii  procedures.  Four  of  these  (Advance,  Await, 
Read,  and  Ticket)  represent  tne  four  user  extended 
instructions  provided  by  the  Event  Manager.  The  remaining 
two  procedures  provide  internal  computational  support  to 
include  necessary  security  checking.  The  Event  Manager  is 
invoiced  solely  by  user  processes,  via  tne  Gate  Keeper, 
through  utiiitation  of  the  extended  instruction  set 
provided.  For  every  Event  Manager  extended  instruction 
invoiced  by  a  user  process,  tne  non-discretionary  security  is 
verified  by  comparing  the  security  access  classification  of 
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tne  process  invoicing  tne  instruction  wttn  tne  ciasslf i cation 
of  tne  object  (segment)  being  accessed.  Access  to  the  user 
process'  Known  Segment  Table  is  required  by  tne  module  in 
order  to  ascertain  tne  segment  nandle  and  security  class  for 
a  given  segment  number.  The  PLZ/ASM  assembly  language 
listing  for  tne  Event  Manager  module  is  provided  in  Appendix 
A.  A  more  detailed  discussion  of  the  procedures  comprising 
tne  Event  Manager  follows. 

1 .  Support  Procedures 

Tne  procedures  GET_EAN£L£  and  CON VERT_AND_ VERIFY 
provide  internal  support  for  tne  Event  Manager  and  are  not 
visible  to  tne  user  processes.  Procedure  CONVERT_AND_VEEIFY 
is  invoked  by  tne  four  procedures  representing  the 
instruction  set  of  the  Event  Manager.  The  input  parameters 
to  C0NVSP.t_AND_vehif7  are  a  segment  number  and  a  requested 
mode  of  access  (viz.,  read  or  writer.  CON VERT_AND_VER1FY 
returns  a  pointer  to  tne  segment's  handle  and'  a  success 
code.  Procedure  G£T_HANDLE  is  invoked  solely  by 
CON VERT_AND_VEF IFT .  The  input  parameter  to  GET_HAN1)LE  is  tne 
segment  number  received  as  input  by  CONVERT_AND_VERIFY . 
GET_HANDLE  returns  a  pointer  to  tne  segment's  nandle,  a 
pointer  to  tne  segment's  security  classification,  and  a 
success  code.  A  discussion  of  tne  functions  provided  by 
these  support  procedures  follows. 

Procedure  GET_EANDLE  translates  tne  segment  number, 
received  as  input,  into  a  KST  index  number  and  verifies  that 
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the  resulting  index  number  is  valid.  Next  tne  base  address 


iof  tne  process'  KST  is  obtained  from  procedure 
ITC_GET_SEG_?TR.  Tne  KST  index  number  is  tnen  converted  into 
l  a  KST  offset  value  and  added  to  tne  base  address  to  obtain 

tne  appropriate  KST  entry  pointer  for  tne  segment  in 
question.  A  verification  is  tnen  made  to  insure  tnat  tne 
referenced  segment  is  "inown"  to  tne  process.  If  tne  segment 
is  not  Known,  an  error  message  is  returned  to 
C0N7iiRT_AND_7ERIFY.  Otnerwise,  a  pointer  to  tne  segment's 
nandle  is  obtained  to  identify  tne  segment  to  tne  memory 
manager.  A  pointer  to  tne  segment's  security  class  entry  in 
tne  KST  is  also  returned  for  use  in  appropriate  security 
cneclcs . 

Procedure  CONVERT_AND_YERIFY  provides  tne  necessary 
non-discretionary  security  verification  for  tne  extended 
Instruction  set  of  the  Event  Manager.  Procedure  GET_HANDIE 
is  invoked  for  segment  number  verification  and  to  obtain 
pointers  to  tne  segment's  nandle  and  security  class.  If 
G£T_HANDLE  returns  vitn  a  successful  verification,  tne 
process'  security  class  is  compared  to  tne  segment's 
security  class  to  verify  tne  mode  of  access  requested.  A 
request  for  "write"  access  causes  invocation  of  tne  CIASS_E0 
function  in  tne  Non-Dlscrecionary  Security  Module  to  Insure 
tnat  tne  security  classification  of  tne  process  is  equal  to 
the  classification  of  the  eventcount  or  sequencer,  which  is 
the  same  as  tnat  of  tne  segment.  Otherwise,  the  CLASS_GE 
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function  is  called  to  verify  mat  me  process  nas  read 
access.  If  tne  appropriate  security  cnecic  is  unsuccessful, 
an  error  cede  is  returned  by  CONVS?.T_AND_VERIFf .  Otherwise, 
tne  segment  nandie  is  returned  along  with  a  success  code  of 
"succeeded”  indicating  that  tne  user  process  possesses  the 
necessary  security  clearance  to  complete  execution  of  tne 
extended  instruction. 

2.  Read 

Procedure  READ  ascertains  tne  current  value  of  a 
user  specified  eventcount  and  returns  its  value  to  the 
caller.  Tne  input  parameters  to  READ  are  a  segment  number 
and  an  instance  (viz.,  an  event  number).  CON VE3T_AND_VSRIFT 
is  invoiced  with  a  "read"  access  request  to  obtain  tne 
segment's  handle  and  necessary  verification.  "Read"  access 
is  sufficient  for  this  operation  as  it  only  requires 
observation  of  tne  current  eventcount  value  and  performs  no 
data  modification.  If  verification  is  successful,  procedure 
'K*_READ_EVENTCOnNT  is  called  to  obtain  the  eventcount  value. 

3.  T1  ctcet 

Procedure  TICKET  returns  the  current  sequencer  value 
for  the  segment  specified  by  the  user.  CONVERT_AND_VERIF I  is 
called  with  a  request  for  write  access  to  obtain 
verification  and  the  segment  handle,  rfrite  access  is 
required  because  once  tne  sequencer  value  is  read  it  must  be 
incremented  in  anticipation  of  the  next  ticket  reauest.  Cnee 
verification  is  complete,  *1M_TICXET  is  invoiced  to  obtain  the 


“1 


sequencer  value  that  is  returned  to  tfte  user  process.  It  is 
noted  tnat  every  call  to  TICKET  for  a  particular  segment 
number  will  return  a  unique  and  time  ordered  sequencer 
value.  This  is  because  tne  sequencer  value  may  only  be  read 
within  MPJTICKET  wnile  the  G_AST  is  locked,  thereby 
preventing  simultaneous  read  operations.  Futhermore,  once 
the  sequencer  value  is  read  it  is  incremented  before  the 
G_AST  is  unlocked. 

4 .  Await 

Procedure  AWAIT  allows  a  user  process  to  blocfc 
itself  until  some  specified  event  has  occurred.  The 
parameters  to  AWAIT  include  a  segment  number  and  instance, 
which  Identify  a  particular  event,  and  a  user  specified 
value  which  identifies  a  particular  occurrence  of  the  event. 
Verification  of  read  access  and  a  pointer  to  tne  segment's 
handle  is  obtained  from  procedure  CONVERT_AND_VERIFI . 
Procedure  TC_AWAIT  is  invoked  to  effect  tne  actual  waiting 
for  the  event  occurrence.  TC_AWAIT  will  not  return  to  AWAIT 
until  the  requested  event  has  occurred.  It  is  ncted  tnat 
AWAIT  maKes  no  assumptions  about  the  event  value  specified 
Ky  the  user.  Therefore,  the  Kernel  cannot  guarantee  that  the 
event  specified  by  the  user  will  ever  occur;  this  is  the 
responsibility  of  other  cooperating  user  processes. 

b.  Advance 

Procedure  AL'VANCE  allows  a  user  process  to  broadcast 
the  occurrence  of  some  event.  This  is  accomplished  by 
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incrementing  tne  value  of  tne  eventcount  associated  with  tne 
event  tnat  has  occurred.  The  parameters  to  ADVANCE  include  a 
segment  number  ana  instance  wnicn  Identify  a  particular 
event.  The  calling  process  must  nave  write  access  to  the 
identified  segment  as  modification  of  the  eventcount  is 
required.  Verification  of  write  access  ana  a  pointer  to  tne 
segment's  handle  is  obtained  through  procedure 
CON  V£F.T_ANP_  VERIFY.  Procedure  TC_AD  VANCE  is  invoiced  to 
perform  the  actual  broadcasting  of  event  occurrence. 

£.  TRAFFIC  CONTROLLER  MODULE 

The  primary  functions  of  the  Traffic  Controller  module 
are  user  process  scheduling  and  support  of  tne  inter-process 
communication  mechanism.  The  Traffic  Controller  Is  invoiced 
by  tne  occurrence  of  a  virtual  preempt  interrupt  and  ty  tne 
Event  Manager  and  the  Segment  Manager  through  tne  extended 
instruction  set:  TC_Advance ,  TC_Avalt,  Process_Class ,  and 
Get_DBR_N’JMBEP.  The  Traffic  Controller  module  is  comprised 
of  nine  procedures.  Four  of  these  procedures  represent  the 
extended  instruction  set  of  the  Traffic  Controller.  A 
detailed  discussion  of  six  of  the  procedures  contained  in 
the  Traffic  Controller  module  is  presented  below.  The 
remaining  tnree  procedures  (viz.,  TC_INIT,  CREATE_PRCCt’SS , 
and  C*EATE_KST)  were  described  in  chapter  tnree.  The  PLZ/ASM 
assembly  language  source  code  listings  for  the  Traffic 
Controller  module  is  provided  in  Appendix  £. 


1 .  TC  Getworlc 

Procedure  TC_GETVrfORK.  provides  tne  mechanism  for  user 

process  scheduling.  The  input  parameters  to  TC_Gi'rWORK  are 

tne  7P  ID  of  tne  virtual  processor  to  wnicn  a  process  will 

be  scheduled  and  the  logical  CPU  number  to  which  the  virtual 

processor  belongs.  Tne  determination  of  wnicn  process  to 

schedule  is  made  by  a  looping  mechanism  that  finds  the  first 
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ready  process  on  the  ready  list  associated  with  the 
current  logical  CPU  number.  Processes  appear  in  the  ready 
list  by  order  of  priority.  This  looping  mechanism  is 
required  as  both  "running"  and  "ready"  processes  are 
maintained  on  the  ready  list.  This  ready  list  structure  was 
cnosen  to  simplify  tne  algorithm  provided  in  procedure 
TC_Advance.  If  a  ready  process  is  found,  its  state  is 
cnanged  to  "running"  and  its  process  IE  (viz.,  tne  APT  entry 
number^  is  inserted  in  tne  running  list  entry  associated 
wi  tn  tne  current  virtual  processor.  Procedure  S'j/AP_VEBR  is 
then  invoiced  in  tne  Inner  Traffic  Controller  to  effect  the 
actual  process  switch.  If  a  ready  process  was  not  found 
(viz.,  the  ready  list  was  empty  or  comprised  solely  of 
"running  processes"),  tnen  tne  running  list  entry  associated 
with  the  current  virtual  processor  is  marked  with  the 
constant  "ldie_Proc"  and  procedure  IDLE  is  invoked  in  tne 
Inner  Traffic  Controller. 
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'2 .  TC  Await 

Tae  primary  function  of  TC_AWAIT  is  tne 
determination  of  whethe.  some  user  specified  event  nas 
occurred.  If  tne  event  nas  occured,  control  is  returned  to 
tne  caller.  Otnerwise,  the  process  is  blocked  and  another 
process  is  scheduled.  The  input  narameters  to  TC_A'J/AIT  are  a 
pointer  to  a  segment  nandle,  an  instance  (event  number),  and 
a  user  specified  eventcount  value.  TC_AWAIT  initially  locks 
the  Active  Process  Table  and  obtains  the  current  value  of 
tne  eventcount  in  question  by  calling  procedure 
MM_PEAD_Sf ENTCOUN T .  The  determination  of  event  occurrence  is 
made  by  comparing  tne  user  specified  eventcount  value  with 
tne  current  eventcount.  If  the  user  value  is  less  than  or 
equal  to  tne  current  eventcount,  tne  awaited  event  nas 
occurred  and  control  is  returned  to  tne  caller.  Otherwise, 
tne  awaited  event  nas  not  yet  occurred  and  tne  process  must 
be  blocked. 

If  the  process  is  to  be  blocked,  procedure 
P.UNN lNG_vp  is  invoked  to  ascertain  tne  7?  ID  of  tn<=  virtual 
processor  bound  to  the  process.  The  process'  IT  (viz.,  APT 
entry  number)  is  then  read  from  the  running  list.  The  input 
parameters  to  TC_AKAIT  (viz.,  Randle,  Instance,  and  Valued 
are  then  stored  in  tne  Event  Data  portion  of  tne  process' 
APT  entry.  The  process  is  removed  from  its  associated  ready 
list  by  redirecting  the  appropriate  linking  threads 
(pointers).  Once  removed  from  tne  ready  list,  tne  process  is 
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threaded  into  the  blocked  list  and  its  state  changed  to 
"blocked"  by  invocation  or  the  library  function  LIST_I NSERT . 
Procedure  TC_GETWORK  is  tnen  called  to  schedule  another 
process  for  the  current  virtual  processor. 

3.  TG  Advance 

The  primary  purpose  of  TC_ADVANCS  is  the 
broadcasting  of  some  event  occurrence.  This  entails 
incrementing  the  eventcount  associated  with  the  event, 
awakening  all  processes  that  are  waiting  for  the  event,  and 
insuring  proper  scheduling  order  by  generating  any  necessary 
virtual  preempt  interrupts.  Tne  nigh  level  design  algorithm 
for  TC_APV  ANCE  is  provided  in  figure  11.  The  input 
parameters  to  TC_ADVANCE  are  a  pointer  to  a  segment's  handle 
and  an  instance  (event  number).  Initially,  TC_ADVANCE  locks 
tne  APT  to  prevent  tne  possibility  of  a  race  condition.  Tne 
eventcount  identified  by  the  input  parameters  is  then 
incremented  by  calling  MM_ADVANCE .  MM_ADVANC£  returns  tne 
new  value  of  tne  eventcount.  Once  the  eventcount  has  been 
advanced,  TC_ADVANCE  awakens  all  processes  awaiting  this 
event  occurrence.  This  is  accomplished  by  checking  all 
processes  that  are  currently  in  tne  blocked  list.  The 
process'  HANDLE  and  INSTANCE  entries  are  compared  with  the 
handle  and  instance  identifying  the  current  event.  If  they 
are  the  same,  tnen  tne  process  is  awaiting  some  occurrence 
of  tne  current  event.  In  such  a  case,  tne  process'  VALUE 
entry  in  the  APT  is  compared  with  the  current  value  of  the 
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TC_ADVANCE  Procedure  (HANDLE,  INSTANCE) 
gin 

!  Get  new  event  count  ! 

COUNT  :=  MM_ADVANCE  (HANDLE,  INSTANCE) 

Cali  tfAlT.LOCK  (APT) 

!  Waite  uo  processes  ! 

PROCESS  :=  BLOCKED  LIST  HEAD 


Do  wnile  not  end  of  BLOCKED_LIST 
If  (PROCESS. HANDLE  *  HANDLE)  and 

(PROCESS .INSTANCE  *  INSTANCE)  and 
(PROCESS. COUNT  <=  COUNT) 
tnen 

Call  LIST  INSERTUEADI  LIST) 
end  if 

PROCESS  :=  PROCESS. NfiXT_PROCESS 
end  do 

!  Cnecfc  ail  ready  lists  for  preempts  ! 
L0GICAL_CPU_N0  :=  1 

Do  wnile  LOGICAL_CPU_NO  <=  #NR_CPU 
!  Initialize  ureempt  vector  T 
VP_ID  :*  FIRST_VP(LOGICAL_CPU_NO) 

Do  for  LOOP  :=  1  to  NR  VP( LOGICAL  CPU  NO 
RUNNING_LIST[VP_ID| .PREEMPT  :=  #TRUE 

VP_ID  :=  VP_ID  +  1 
end  do 

!  Find  preerpt  candidates  ! 

CANDIDATES  :  =  0 

PROCESS  :=  READV  LIST  HEAD (LOGICAL  CPU  NO) 


Figure  11.  TC_ ADVANCE  Algoritnir 


VP_ID  :=  FIRST_7P(L0GICAL_CPU_N0) 

Do  (for  CYCLE  =  1  to  NR  7?(LQGICAL  CPU  N0)  and 
not  end  of  READ!  LIST(LCGICAL  CPU  NO) 

If  PROCESS  =  #RUNNI NG 
then 

RUNNING  LIST[VP_IDJ .PREEMPT  :=  #FALSE 
else 

CANDIDATES  :=  CANDIDATES  *  1 
end  if 

VP_ID  :=  VP  ID  +  1 
PROCESS  :=  PROCESS. NEXT_PROCESS 
end  do 

!  Preempt  appropriate  candidates  ! 

V°_ ID  :=  FIRST_VP(LOGICAL_CPU_NO  ) 

Do  for  CHECK  :=  1  to  NR  VP(LOGICAl  CPU  NO' 

If  (RUNNING  LIST [VP  IDJ. PREEMPT  =  #TRUE)  and 
(CANDIDATES  >  0)“ 
tnen 

Cali  S£T_PR£EMPT( VP_ ID  ) 

CANDIDATES  :*  CANDIDATES  -  1 
end  if 

VP_ID  :=  VP_ID  ♦  1 
end  do 

IOGICAL_CPU_NO  :*  LOGI CAL_CPTJ_NO  *  1 
end  do 

Call  UNLOCK(APT) 

Return 

End  TC  ADVANCE 


Figure  11.  TC_ADVANCE  Algorithm  (Continued) 
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eventcount.  If  tne  process'  VALUE  is  less  tnan  or  equal  to 
tiie  current  eventcount  value,  tne  awaited  event  nas  occurred 
and  tne  process  is  removed  from  tne  biocired  list  and 
threaded  into  tne  appropriate  ready  list  by  tne  library 
function  LIST_INSERT. 

Once  tne  blocked  list  nas  been  checirea,  it  is 
necessary  to  reevaluate  eacn  ready  list  to  insure  tnat  tne 
nignest  priority  processes  are  running.  It  is  relatively 
simple  to  determine  if  a  virtual  preempt  interrupt  is 
necessary,  nowever,  it  is  considerably  more  difficult  to 
determine  which  virtual  processor  should  receive  the  virtual 
preempt.  To  assist  in  tnis  evaluation,  a  "count"  variable 
(number  of  preempts  needed)  is  zeroed  and  a  preempt  vector 
is  created  on  the  Kernel  stact  with  an  entry  for  every 
virtual  processor  associated  with  the  logical  CPU  being 
evaluated.  Initially,  every  entry  in  tne  preempt  vector  is 
marJted  "true”  indicating  tnat  its  associated  virtual 
processor  is  a  candidate  for  preemption.  Once  the  preempt 
vector  is  initialized,  tne  first  "n"  processes  on  the  ready 
list  (where  n  equals  the  number  of  VP's  associated  with  the 
current  logical  CPU)  are  cnectced  for  a  determination  of 
their  state.  If  a  process  is  found  to  be  "running"  then  it 
snould  not  be  preempted  as  processes  appear  in  tne  ready 
list  in  order  of  priority.  When  a  running  process  is  found, 
its  associated  entry  in  tne  preempt  vector  is  marked 
"false.”  If  a  process  is  encountered  in  tne  "ready"  state 
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running  and 
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incremented . 
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tne  first  "n" 
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or  when  we 
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ready  list 
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comes 

first). 
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.  If  an 
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from  the  preempt 

vector  is 

found 

to  be 

•f  •« 

t  rue  , 

tni  s 

indicates  tnat  its 

associated  virtual  processor  is  a  candidate  for  preemption 
since  it  is  eitfier  bound  to  a  lower  priority  process,  cr  it 
is  "idle."  In  sucn  a  case,  tne  "count"  variable  is  evaluated 
to  determine  if  the  virtual  processor  associated  vitfi  tfte 
vector  entry  should  be  preempted.  If  tne  count  exceeds  zero, 
a  virtual  preempt  interrupt  is  sent  to  tne  VP  and  tne  count 
is  decremented.  Otnerwise,  no  preempt  is  sent  as  tnere  is  r.o 
Higher  priority  process  awaiting  scheduling. 

This  preemption  algorithm  is  completed  for  every 
ready  list  in  the  Active  Process  Table.  Once  all  ready  lists 
nave  been  evaluated,  tne  APT  is  unlocked  and  control  is 
returned  to  tne  caller.  It  is  noted  that  it  is  not  necessary 
to  Invoke  TC_GETWORK  before  exiting  ADVANCE.  If  tne  current 
vp  requires  rescheduling,  it  will  nave  received  a  virtual 
preempt  interrupt  from  tne  preemption  algorithm.  If  this  nas 
occurred,  tne  VP  will  be  rescheduled  wnen  its  running 
process  attempts  to  leave  tne  Kernel  domain  and  tne  virtual 
preempt  interrupts  are  unmasjced. 
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Virtual  Preempt  Handier 


VIRTUAL_PREEMPT_HANDLER  is  the  interrupt  nandler  for 
virtual  preempt  interrupts.  The  entry  address  of 
VIRTUAL_PRSEMPT_HANDLER  is  maintained  in  the  virtual 
interrupt  vector  located  in  the  Inner  Traffic  Controller. 
Once  invoiced,  tne  handler  locics  the  Active  Process  Table  and 
determines  which  virtual  processor  is  being  preempted  by 
calling  RUNNING.VP.  Tne  process  running  on  the  preempted  VP 
is  then  set  to  the  "ready"  state  and  TC.GETWORK  is  invoiced 
to  reschedule  tne  virtual  processor.  When  TC_GETWOR£  returns 
to  VIRTUAL_PREEMPT_HANDLER,  the  APT  is  unlocked  and  a 
virtual  interrupt  return  is  executed.  This  return  is  simply 
a  jump  to  the  point  in  the  hardware  preempt  handler  where 
tne  virtual  interrupts  are  unmaslred.  This  effects  a  virtual 
interrupt  return  instruction. 

5,  Remaining  Procedures 

The  remaining  two  procedures  in  the  Traffic 
Controller  module  represent  the  extended  instructions: 
PROCESS_CLASS  and  GET_DBR_nUMBER .  Both  procedures  locfc  the 
Active  Process  Table  and  call  RUNNING_VP  to  determine  which 
virtual  processor  is  executing  the  current  process.  Tr.e 
process  ID  (vit.,  APT  entry  Number)  is  then  extracted  from 
the  running  list.  PROCESS  CLASS  reads  and  returns  the 
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number  provided  by  procedure  GBT_DBR_NUMBER  is  only  valid 
while  the  APT  is  locked.  Particularly ,  in  the  current  SASS 
implementation,  tne  Segment  Manager  invokes  GET_DEP_NUMBER 
and  then  passes  the  obtained  DBR  number  to  the  Distributed 
Memory  Manager  for  utilization  at  that  level.  In  a  more 
general  situation,  the  process  associated  with  the  DBR 
number  may  nave  been  unloaded  before  the  DBR  number  was 
utilized,  thus  making  it  invalid.  This  problem  does  not 
arise  in  SASS  as  ail  processes  remain  loaded  for  the  life  of 
the  system. 

C.  DISTRIBUTED  MEMORY  MANAGER  MODULE 

The  Distributed  Memory  Manager  module  provides  an 
interface  between  the  Segment  Manager  and  tne  Memory  Manager 
process,  manipulates  event  data  in  the  Global  Active  Segment 
Table  (G_AST) ,  and  dynamically  allocates  available  memory.  A 
detailed  description  of  tne  Distributed  Memory  Manager 
interface  to  the  Memory  Manager  process  was  presented  by 
Wells  [6],  The  remaining  extended  instruction  set  is 
discussed  in  detail  below.  The  complete  PLZ/ASM  source 
listings  for  the  Distributed  Memory  Manager  module  is 
provided  in  Appendix  C. 

1 .  MM  Read  Eventcount 

MM_READ_EVENTCOUNT  is  invoked  by  the  Event  Manager 
and  tne  Traffic  Controller  to  obtain  tne  current  value  of 
the  eventcount  associated  with  a  particular  event.  The  input 
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parameters  to  this  procedure  are  a  segment  nandle  pointer 
and  an  instance  (event  Number),  which  together  uniquely 
identify  a  particular  event. 


The  G_AST  is  locked  and  the  entry  offset  of  tee 
segment  into  the  G_AST  is  obtained  from  the  segment's 
handle.  The  Instance  parameter  is  then  validated  to 
determine  which  eventcount  is  to  be  read.  If  an  invalid 
instance  is  specified,  control  is  returned  to  the  caller 
specifying  an  error  condition.  Otherwise,  the  current  value 
of  the  specified  eventcount  is  read.  The  G_aST  Is  then 
unlocked,  and  the  current  eventcount  value  is  returned  to 
tne  caller. 

2.  Advance 

MMJLEVANCE  is  invoked  by  the  Traffic  Controller  to 
reflect  the  occurrence  of  some  event.  The  input  parameters 
to  MM_ADVANCE  are  a  pointer  to  a  segment's  handle  and  a 
particular  instance  (event  number). 

The  Global  Active  Segment  Table  is  locked  to  prevent 
a  race  condition,  and  the  offset  of  the  segment's  entry  into 
tne  G_AST  is  obtained  from  the  segment  handle.  The  instance 
parameter  is  then  validated  to  determine  which  eventcount  is 
to  be  advanced.  If  an  invalid  instance  is  specified,  an 
error  condition  is  returned  to  the  caller  and  no  data 
entries  are  affected.  If  the  instance  value  is  valid,  the 
appropriate  eventcount  is  incremented,  and  its  new  value  is 


returned 


3.  MM  Ticaet 


MM_TICKET  is  invoiced  by  tne  Event  Manager  to  obtain 
tne  current  value  of  tne  sequencer  associated  witft  a 
specified  segment.  Tne  input  parameter  to  MM_TICKET  is  a 
pointer  to  a  segment's  handle. 

Initially,  MM_TICEET  loots  tne  Global  Active  Segment 
Table  to  prevent  a  race  condition.  Next  the  offset  of  the 
segment's  entry  into  tne  G_AST  is  obtained  from  tne  segment 
nandle.  Tne  current  value  of  the  sequencer  for  tne  specified 
segment  is  tnen  read  and  saved  as  a  return  parameter  to  tne 
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4.  MM  Allocate 

Tne  MM_ALLOCATS  procedure  provided  in  this 
implementation  is  a  stub  of  tne  MM_A1L0CATE  described  in  tne 
Memory  Manager  design  of  Moore  and  Gary  [4] . 

Tne  primary  function  of  MM_ALLOCATE  is  tne  dynamic 
allocation  of  fixed  size  biocts  of  available  memory  space. 


It  is 

invoiced 

in  tne 

current  implementation 

by 

tne 

ini tla 

lization 

routines 

in  B00TSTRAP_ LOADER  and  TC_ 

INI? 

for 

tne  ai 

location 

of  memory 

space  used  in  tne  creation 

of 

tne 

Kernel 

domain 

and  Supervisor  domain  stact  segments 

and 

tne 

creation  of  tne  Known  Segment  Tables  for  user  processes. 
Dynamic  reallocation  of  previously  used  memory  space  (viz., 
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garbage  collection)  is  not  provided  by  tne  MM_AILOCATS  stub 
in  tnis  implementation.  Ail  memory  allocation  required  in 
tnis  implementation  is  for  segments  supporting  system 
processes  tdat  remain  active,  and  tnus  allocated,  for  tne 
entire  life  of  tne  system.  Memory  is  allocated  in  blocks  of 
256  (decimal)  bytes  of  processor  local  memory  (on-board 
RAM).  In  tnis  stub  allocatable  memory  is  declared  at  compile 
time  by  a  data  structure  (MEM_PQ0L)  tnat  is  accessible  only 
by  mm_ALLOCATE. 

Tne  input  parameter  to  MM_ALLOCATE  is  tne  number  of 
blocics  of  requested  memory.  Tnis  parameter  is  converted  from 
a  block  size  to  tne  actual  number  of  bytes  requested.  Tnis 
computation  is  made  simple  since  memory  is  allocated  in 
powers  of  two.  Tne  byte  size  is  obtained  by  logically 
snirtine  left  tne  input  parameter  eigfct  times,  wnere  eignt 
is  tne  power  of  two  desired  (viz.,  256).  Once  tne  size  of 
the  reauested  memory  is  computed,  it  is  necessary  to 
determine  tne  starting  address  of  tne  memory  blocK(s)  to  be 
allocated.  To  assist  in  tnis  computation,  a  variable 
(NBXT_BLOCK)  is  used  to  keep  track  of  tne  next  available 
block  of  memory  in  MEM_POOL.  NEXT_BLOCK,  wnicn  is 
initialized  as  zero,  provides  tne  offset  into  tne  memory 
being  allocated.  Once  tne  starting  address  is  obtained,  tne 
pnysical  size  of  tne  memory  allocated  is  added  to  NEXT_2ICCK 
so  tnat  tne  next  request  for  memory  allocation  will  begin  at 
tne  next  free  byte  of  memory  in  MEM_P00L.  Tnis  new  value  of 
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N£XT_BLOCK  is  saved  and  tne  starting  address  of  tne  memory 
for  this  request  is  returned  to  tae  caller. 

D.  GATE  KEEPER  MODULES 

The  S ASS  Gate  Keeper  provides  tae  logical  boundary 
between  tne  Supervisor  and  tne  Kernel  and  isolates  tne 
Kernel  from  tne  system  users,  tnus  malting  it  tamperproof. 
Tnis  is  accomplisned  by  means  of  tne  nardvare  system/normal 
mode  and  the  software  ring-crossing  mechanism  provided  by 
tne  Gate  Keeper.  Tne  Gate  Keeper  is  comprised  of  two 
separate  modules:  l)  tne  USER_GATE  module,  and  2)  tne 
KERNEL_GATE_ KEEPER  module.  Tnese  modules  are  disjoint,  witn 
tne  US£R_GATE  module  residing  in  the  Supervisor  domain  and 
tne  KERNEL_GATE_KEEPER  module  residing  in  tne  Kernel  domain. 
It  is  important  to  note  tnat  the  USER_GATE  is  a  separately 
United  component  in  tne  Supervisor  domain  and  is  not  United 
to  the  Kernel.  The  only  tning  in  common  between  tnese  two 
modules  is  a  set  of  constants  identifying  tne  valid  extended 
instruction  set  which  tne  Kernel  provides  to  tne  users. 

The  Gate  Keeper  modules  presented  in  tnis  implenemtation 
are  only  stubs  as  they  do  not  provide  ail  of  the  functions 
required  of  the  Gate  Keeper.  However,  the  only  tasic  not 
provided  in  tnis  implementation  is  tne  validation  of 
parameters  passed  from  the  Supervisor  to  the  Kernel.  A 
detailed  description  of  tnis  parameter  validation  design  is 
provided  by  Coleman  13]  .  In  the  process  management 
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demonstration,  tne  Supervisor  stubs  are  written  in  PLZ/ASM 
with  all  parameters  passed  by  CPU  registers.  A  detailed 
description  of  the  Gate  Keeper  modules  and  the  nature  of 
their  Interfaces  is  presented  below.  The  PLZ/ASM  source 
listings  for  the  two  Gate  Keeper  modules  are  provided  in 
Appendix  C. 

1 .  User  Gate  Module 

The  USER_GATE  module  provides  the  interface 
structure  between  tne  user  processes  in  tne  Supervisor 
domain  and  the  Kernel.  The  TJSER_GATE  is  comprised  of  ten 
procedures  (viz.,  entry  points)  that  correlate  on  a  one  to 
one  basis  with  the  ten  "user  visible"  extended  instructions 
(listed  in  figure  6)  provided  by  the  Kernel.  The  only  action 
performed  by  each  of  these  procedures  is  tne  execution  of 
the  "system  call"  Instruction  (SC)  with  a  constant  value, 
identifying  the  particular  extended  instruction  invoiced,  as 
the  source  operand. 

The  SC  instruction  is  a  system  trap  tnat  forces  tne 
hardware  into  the  system  mode  (Kernel  domain)  and  loads 
register  15  with  tne  system  stack  pointer  (Kernel  domain 
stack).  The  current  instruction  counter  value  (IC)  is  pushed 
onto  tne  Kernel  stack  along  with  tne  current  CPU  flag 
control  word  (PCW).  In  addition,  the  system  trap  instruction 
is  pushed  onto  tne  Kernel  stack  with  tne  upper  byte 
representing  the  SC  instruction  and  the  lower  byte 


representing  tne  SC  Instruction's  source  operand  (viz.. 


tne 


Kernel  extended  instruction  code).  Together,  these 
operations  form  an  interrupt  return  ( IRET )  frane  as 
illustrated  in  figure  9.  Once  tnis  is  complete,  tee  i'CW  is 
loaded  witn  tne  FC 'll  value  found  in  tne  System  Call  frame  of 
tbe  Program  Status  Area  (viz.,  tne  hardware  "interrupt 
vector").  Tne  structure  of  tne  Program  Status  Area  is 
illustrated  in  figure  12.  Tne  instruction  counter  is  tnen 
loaded  witn  tne  address  of  tne  SC  instruction  trap  nandier. 
This  value  is  also  located  in  tne  SC  frame  of  the  Program 
Status  Area. 

2.  Kernel  Gate  Keeper  Module 

The  system  trap  nandier  for  the  System  Call 
instruction  is  the  KERNEL_GATE_KEEPER .  The  address  of  tne 
KERN EL_GATE_ KEEPER  and  the  Kernel  FCW  value  are  placed  in 
the  System  Call  frame  of  tne  Program  Status  Area  by  the 
BOOTS TRAP _LOADER  module  during  initialization.  The 
KERNEL_GATE_KEEPER  fetches  the  extended  instruction  code 
from  tne  trap  instruction  entry  in  the  IRET  frame  on  the 
Kernel  stack.  This  value  is  then  decoded  oy  a  "case" 
statement  to  determine  which  extended  instruction  is  to  be 
executed.  If  the  extended  instruction  code  is  valid,  the 
appropriate  Kernel  procedure  is  invoked.  Otherwise,  an  error 
condition  is  set  and  no  Kernel  procedures  are  not  invoked. 
Once  control  returns  to  tne  KERNEI_GATE_KEEPER ,  tne  CPU 
registers  and  normal  stack  pointer  (NSP)  value  are  pushed 
onto  tne  Kernel  stack  in  preparation  for  return  to  tne 
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OFFSET 


e  !- 
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\ 

Reserved  i 

! — Frames 

4  r 
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Instruction  ! 

Trap  ! 

Kernel  FCW  ! 
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i 

Kernel  Gate  Keeper  | 
Address  1 

i  Lai  1 

! Instruction 
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1 

1 0  \ 
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1 

OM  1  _ 

Segment  ! 

Trap  ! 
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1 
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1 

•>  A  1  . 
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Interrupt  ! 
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1 

1 

Kernel  FCW  ! 

**  i  rarCWare 
! Preempt 

! PEYS_PEEEMPT_HANriER j 
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'I  *.>  1  1 

!  { Nor.- 
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—  I  Interrupt) 

C  C.  1 

1 

\ 

\ 

1 

1 

1 

> 

•  ! 

1 

•  1 

1 

•  t 

NOTE:  Offsets  represent  Program  Status  Area  structure 
for  non-s egmented  Z&kUZ  microprocessor. 


Figure  12.  Program  Status  Area 
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Supervisor  domain.  It  is  noted  tnat  this  operation  would 
normally  occur  immediately  upon  entry  into  tne 
KERNEL_GATE_KEEPER .  In  this  implementation,  nowever, 
parameter  validation  is  not  accomplished  and  the  CPU 
registers  are  used  to  pass  parameters  to  and  from  the  Kernel 
only  for  use  by  the  process  manaeement  demonstration.  In  an 
actual  SASS  environment,  ail  parameters  would  be  passed  in  a 
separate  argument  list  and  the  CPU  registers  would  appear 
exactly  the  same  upon  leaving  the  Kernel  as  they  did  upon 
entering  the  Kernel.  This  is  important  to  insure  that  no 
data  or  information  is  leaked  from  the  Kernel  by  means  of 
the  CPU  registers. 

Control  is  returned  to  tne  Supervisor  by  means  of  tne 
return  mechanism  in  the  hardware  preempt  handier.  This 
mechanism  is  utilized  to  preclude  tne  necessity  of  building 
a  separate  mechanism  for  tne  KERNEI_GATE_ KEEPER  that  would 
actually  perform  tne  very  same  function.  To  accompiisn  this, 
the  KERNEL_GATE_KEEPER  executes  an  unconditional  Jump  to  the 
PREEMPT_RET  label  in  PHY S_PREEMPT_HANDLER .  This  "jump"  to 
the  hardware  preempt  handler  represents  a  "virtual  IRE?" 
instruction  providing  tne  same  function  as  tne  virtual 
interrupt  return  described  in  the  discussion  of  the  virtual 
preempt  handler.  At  this  point,  tne  virtual  preempt 
interrupts  are  unmasked,  the  normal  stack  pointer  and  CPU 
registers  are  restored  from  the  stack,  and  control  is 
returned  to  the  Supervisor  by  execution  of  the  IRET 
instruction. 
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S.  SUMMARY 


T he  implementation  of  process  management  functions  for 
tne  SASS  nas  been  presented  in  tnls  cnapter.  Tne 
implementation  was  discussed  in  terms  of  the  Event  Manager, 
Traffic  Controller,  Distributee  Memory  Manager,  and  Gate 
Keeper  modules. 

Cnapter  V  will  present  tne  conclusions  drawn  from  tnis 
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The  implementation  of  process  management  for  the 
security  Kernel  of  a  secure  arcnival  storage  system  nas  teen 
presented.  The  process  management  functions  presented 
provide  a  logical  and  efficient  means  of  process  creation, 
control,  and  scheduling.  In  addition,  a  simple  but  effective 
mechanism  for  inter-process  communication,  based  on  tne 
eventcount  and  sequencer  primitives,  was  created.  Work  was 
also  completed  in  tne  area  of  Kernel  database  initialization 
and  a  Gate  Keeper  stub  to  allow  for  dual  domain  operation. 

Tne  design  for  this  implementation  was  based  on  tne 
Zilog  Z8001  sixteen  bit  segmented  microprocessor  [l?J  used 
in  conjunction  witn  tne  Zilog  Z8010  Memory  management  Unit 
[18].  The  actual  implementation  of  process  management  for 
the  SASS  was  conducted  on  the  Advanced  micro  Computers 
Am^ti/4116  MonoBoard  Computer  Tiy]  featuring  tne  AmZS002 
sixteen  bit  non-segmented  microprocessor.  Segmentation 
hardware  was  simulated  by  a  software  Memory  Management  Unit 
Image . 

Tnis  implementation  was  effected  specifically  to  support 
tne  Secure  Archival  Storage  System  (SASS)  I2lj.  However,  tne 
implementation  is  based  on  a  family  of  Operating  Systems  [lj 
designed  witn  a  primary  goal  of  providing  multilevel 
information  security.  Tne  loop  free  modular  design  utilized 
in  tnis  implementation  easily  facilitates  any  required 
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expansion  or  modification  for  otner  family  renters.  In 
addition,  tnis  implementation  fully  supports  a 
multiprocessor  design.  Wnile  tne  process  management 
implementation  appears  to  perform  correctly,  it  nas  not  been 
subjected  to  a  formal  test  plan.  Sncn  a  test  plan  snould  be 
developed  and  implemented  before  Kernel  verification  is 
begun . 

A.  FOLLOW  ON  WORK 

Tftere  are  several  possible  areas  in  tne  SASS  design  tnat 
would  be  immediately  suitable  for  continued  research.  In  tne 
area  of  nardware,  tnis  includes,  tne  es ta bli snment  of  a 
multiprocessor  environment,  nardware  initialization,  and 
interfacing  to  tne  nost  computers  and  secondary  storage. 
Further  wort  in  tne  Kernel  includes  tne  actual 
implementation  of  the  memory  manager  process,  and  the 
refinement  of  tne  Gate  Keeper  and  Kernel  intiali zation 
structures.  The  implementation  of  tne  Supervisor  nas  not 
teen  addressed  to  date.  Its  areas  of  research  include  tne 
implementation  of  tne  File  Manager  and  Input/Cutput 
processes,  and  tne  final  design  and  implementation  of  tne 
SASS-Hosts  protocols. 

Otner  areas  tnat  could  also  prove  interesting  in 
relation  to  tne  SASS  include  tne  implementation  of  dynamic 
memory  management,  tne  support  of  multilevel  nosts,  dynamic 
process  creation  and  deletion,  and  tne  provision  of 
constructive  wor*  to  be  performed  by  tne  Idle  process. 


APPENDIX  A  -  EVENT  MANAGER  LISTINGS 


ZS000ASM  2.02 
LOC  OSJ  CODE 


STMT  SOURCE  STATEMENT 


HISTON  $TTY 
EVENT  MGR 


MODULE 


CONSTANT 

TRUE 

FALSE 

READ_ACCESS 
WRITE  ACCESS 
SUCCEEDED 
SEGMENT  NOT  KNOWN 
ACCESS_C1ASS  NOT_EC 
ACCESS_CLASS~NOT  G£ 
KST_SEG  NO 
NR_OF  KSEGS 
MAX_NO_KST  ENTRIES 
NOT  KNOWN 


TV?E 

H  ARRAY 


ARRAY [3  WORD J 


KST_REC  RECORD 
[MM_HANDLE  H  ARRAY 
SIZE  WORD 

ACCESS  MODE  BYTE 
IN_C0RE  BYTE 

CLASS  LONG 

M_S EG  NO  SHORT  INTEGER 

ENTPY'nUMSER  SHORT  INTEGER 


EXTERNAL 

MM  TICKET  PROCEDURE 

MM  READ  EVENTCOUNT  PROCEDURE 
TC"ADVAFJCE  PROCEDURE 

TC  AWAIT  PROCEDURE 

PROCESS  CLASS  PROCEDURE 
CIASS_EC  PROCEDURE 

CLASS  GE  PROCEDURE 

ITC  GET  SEG  PTR  PROCEDURE 
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0000 


internal 

^SECTION  EM_£ST  DC! 

!  NOTE:  THIS  SECTION  IS  AN  ” OVERLAY" 

OR  "frame’  used  to  define  the 

FORMAT  OF  THE  KST .  NO  STORAGE  IS 
ASSIGNED  BUT  RATHER  THE  EST  IS 
STORED  IN  A  SEPARATELY  OBTAINED 
AREA.  (A  SEGMENT  SET  ASIDE  FOR  IT)! 

$ABS  0 

KST  ARRAY [MAX_NO_KST_ENTP IES  KST_RECJ 


105 


GLOBAL 

SSECTION  EM  GLB  PROC 


0000  READ  PROCEDURE 

f  **x*  t*  9*********f  ********  W‘*t***3***V‘’***  ********** 

*  READS  SPECIFIED  EVENTCOUNT  * 

*  AND  RETURNS  IT'S  VALUE  TO  * 

*  THE  CALLER  * 

7*****i*****X***************************l***********X******* 


*  PARAMETERS:  v 

*  Rl:  SEGMENT  #  * 

*  R2 :  INSTANCE  * 

******  Iff*  ********!*****  if  ************  **^t  ******** 


*  RETURNS:  * 

*  R0:  SUCCESS  CODE  * 


*  RR4 : 

EVENTCOUNT 

»*»W **l***9S***l*7***>f  **************  jf]*>*X*l*l*)*l*  J 

ENTR* 

!  SAVE 

INSTANCE  ! 

0000 

93F2 

PUSH 

0R15.  R2 

!  ”?EAD"  ACCESS  REOUIRED  ! 

0002 

2102 

LD 

R2,  #READ_ACCESS 

0004 

0001 

!  GET 

SEG  HANDLE  *  VERIFY 

ACCESS  ! 

0006 

5F00 

CALL 

CONVERT. AN D_ VERIFY 

!R1:SJSG  * 

0008 

0000  ' 

R2 :RE0 .  ACCESS 
RETURNS: 

R0  : SUCCESS  CODE 
Rl :HANDLE  PTR ! 

000A 

0B00 

C® 

P.0  ,  #SUCCEEDED 

000C 

0002 

IF  EO 

JACCESS  PERMITTED! 

000E 

5E0E 

THEN 

! READ  EVENTCOUNT! 

0010 

001c' 

! RESTORE  INSTANCE! 

0012 

97F2 

POP 

R2f  PR 15 

0014 

5F00 

CALL 

MM_READ_EV  ENTCOUNT 

! Rl : HPTR 

0016 

0000* 

R2: INSTANCE 
RETURNS : 

R0 : SUCCESS  CODE 
RR4  :E VENT COUNT ! 

0019 

5E08 

ELSE 

!REST0RE  SP! 

001A 

001E ' 

001C 

97F2 

POP 

R2 1  0R15 

FI 

001S 

9E08 

RET 

0020 

END  READ 
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Kfl 


fPT  ®T  V 


*  bh* 


ee2e 


TICKET  PP.CCEDURE 

i  *****¥¥  ¥¥¥***¥*** ********* 

*  RETURNS  CURRENT  VALUE  OF  * 

*  TICKET  TO  CALLER  AND  INCRE-  * 

*  I* ENTS  SEQUENCER  FOR  NEXT  * 

*  TICKET  OPERATION  * 

*  PARAMETERS:  1(1 

*  Ri:  SEGMENT  #  * 

***>*¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥ 

*  RETURNS:  * 

*  R0 :  SUCCESS  CODE  * 

*  RR4 :  TICKET  VALUE  * 

*¥¥¥¥¥¥¥*¥¥¥¥*¥?¥*¥**¥*¥¥*¥¥*¥¥  J 

ENTRY 

!  GET  SEC-  HANDLE  &  VERIFY  ACCESS  ! 

!  "WRITE"  ACCESS  REQUIRED  ! 

0020  2102  LD  R2,  #WRITE_ACCESS 

0022  00ee 

0024  5F00  CALL  CONVERT_AND_ VERIFY  !R1:SEG  # 

002b  0000  ' 

R2:ACCSSS  RFC 
RETURNS  : 

R0 : SUCCESS  COD 
Rl  .'HANDLE  PTR ! 

0028  0E00  CP  R0,  ^SUCCEEDED 

002A  0002 

IF  EQ  JACCESS  PERMITTED! 

0fc2C  5E0E  THEN  !  GET  TICKET  ! 

002E  0038  * 

0030  5F00  CALL  MM  TICKET  !R1 :KANDLE  PTR 

0032  e000» 

RETURNS  : 

RR4  :?ICKET ! 

!  RSTORE  SUCCESS  CODE  ! 

0034  2100  LD  Re,  ^SUCCEEDED 

0036  0002 

FI 

0038  9Eee  RET 
003A  END  TICKET 


003A  AWAIT  PROCEDURE 

*  CURRENT  EVENT COUNT  VALUE  IS  * 

*  COMPARED  TO  USER  SPECIFIED  * 

*  VALUE.  IP  USER  VALUE  IS  * 

*  GREATER  THAN  CURRENT  EVENT-  * 

*  COUNT  VALUE  THEN  PROCESS  IS  * 

*  "BLOCKED"  UNTIL  THE  DESIRED  * 

*  EVENT  OCCURS  .  * 

VMVW  WVVM  W  W  J?  W  V  W  WWWJ?  W  V 


* 

PARAMETERS: 

* 

* 

HI:  SEGMENT  # 

* 

* 

R2:  INSTANCE  (EVENT  *) 

* 

RR4  .*  SPECIFIED  VALUE 

9 

V 

RETURNS: 

* 

Re:  SUCCESS  CODE 

* 

vqcjgcqcjp  JfOjt  w  **«>**  Jit  W  VW  DO*  St  1 


003A  91F4 
003C  93T2 
003E  2102 

ee4e  0001 

0042  5F00 
0044  0000' 


0046  0B00 
0048  0002 

004A  5E0S 
004C  005A ' 

004E  97F2 

0060  95F4 
0052  5F00 
0054  0000** 


ENTRY 

!  SAVE  DESIRED  EVENTCOUNT  VALUE  ! 

PUSRL  0P.15,  RR4 
!  SAVE  INSTANCE  ! 

PUSH  0R15,  R2 
!  "READ”  ACCESS  REQUIRED  ! 

LD  R2 ,  #READ_ACCESS 

!  GET  SSG  HANDLE  &  VERIFY  ACCESS  f 
CAIL  CONVERT  J1ND_VERIFT  !R1:SEG  # 

R2  :ACCESS  F.EQ 
RETURNS: 

R0  :SUCCESS  CODS 
R1  : HANDLE  PTR! 

C?  R0 ,  ^SUCCEEDED 

IF  EC  !  ACCESS  PERMITTED  » 

THEN  !  AWAIT  EVENT  OCCURRENCE  » 

!  RESTORE  INSTANCE  ! 

POP  R2 ,  PR15 

J  RESTORE  SPECIFIED  VALUE  l 
POPL  RR4,  PRls 

CALL  TC_AWAIT  !R1 ’.HANDLE  PTR 

R2:  INSTANCE 
RR4:  VALUE 
RETURNS: 

30  :SUCCESS  CODS’ 
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•aw 


I 


ELSE  !  RESTORE  STACK 


0056  5E08 
0058  005E 
005A  95F4  POP!  RR4,  8R15 

005C  97E2  POP  P.2,  GR15 

FI 

005E  9E08  RET 
0060  END  AWAIT 
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ADVANCE  procedure 

f  VW  w  w vvvvwvv vwm  wv  w 

'*  signals  the  occurrence  of  * 

*  SOME  EVENT.  EV ENTCODNT  IS  * 

^  incremented  and  the  traffic  * 

*  CONTROLIER  IS  INVOKED  TO  * 

*  awaken  ant  process  awaiting  * 

*  THE  OCCURRENCE.  * 

w  9  99  4>  *¥  *  * *«  * *  *  W *  **  V  *  **  *  *  **  ** 

*  PARAMETERS:  1,1 

v  Ri :  SEGMENT  #  * 

*  R2 :  INSTANCE  (EVENT  *0  * 

999  99  9  999999^^9^9  999  99^^9^^9^9 

*  RETURNS:  * 

*  R0:  SUCCESS  CODE  * 

999 v* » ww w www* 99999999*9** ; 


0060  93F2 


04)62  2102 
0064  0000 
0066  bF00 
0068  0000' 


006A  0B00 
006C  0002 

006S  5E0E 
0070  007C ' 

0072  97F2 

0074  bF00 
0076  0000** 


0078  5E08 
007 A  007E ' 
007C  9?F2 

007 E  9S08 
0080 


ENTRY 

!  SAVE  INSTANCE  • 

PUSH  0R15,  R2 

!  GET  SEG  HANDLE  &  VERIFY  ACCESS  ! 

!  "WRITE"  ACCESS  REQUIRED  ! 

LD  R2,  #WRITE_ACCESS 

CALL  C0NVERT_AND_VERIFY  !R1:SEG  # 


R0 ,  ^SUCCEEDED 


R2 .-ACCESS  REC 
RETURNS: 

R0  rSUCCESS  CODE 
Rl: HANDLE  PTP! 


IF  SQ  !  ACCESS  PERMITTED  ! 

THEN  !  ADVANCED  SVENTCOUNT  ! 

!  RESTORE  INSTANCE  ! 

POP  R2,  <?Rlb 

CALL  TC_ADV ANCE  !R1:HANELE  PTR 

R2: INSTANCE 
RETURNS  : 

R0  :SUCCESS  CODE! 
ELSE  'RESTORE  STACK! 

POP  R2 ,  @R15 
FI 
RET 

END  ADVANCE 


-«*>■ 


INTERNAL 

$S ACTION  EM_lNT_PP.OC 

0000  CCNVERT_ANE_V  ERIFY  PRO C£ EURE 

{  VWMM  WW  W>?  VV  W  W  V  WW  ww  WMVMW  MV 

*  CONVERTS  SEGMENT  NUMBER  TO  KST  INDEX* 

*  ANE  EXTRACTS  SEGMENT'S  HANDLE  IRQ*  * 

*  1ST.  IF  SUCCESSFUL,  THEN  ACCESS  * 

*  CLASS  OF  SUBJECT  IS  CHECKED  AGAINST  * 

*  ACCESS  CLASS  OF  OBJECT  TO  INSURE  * 

9  THAT  ACCESS  IS  PERMITTED.  * 

9  ¥  *  *  *  V  *  W  *  *  XC  *  v  V  W  W  W*  *  a*  «  *  *  v  *  *  **  *  a*  « agcjgc 

*  PARAMETERS:  * 

*  Ri:  SEGMENT  NUMBER  » 

*  R2 :  ACCESS  REQUESTED  * 

ajC»cvaj(VV*>g‘VV«V«VWWV*t*c  ««v*V*ww***V*W)!l*** 

9  RETURNS:  * 

*  R0 :  SUCCESS  CODE  * 

*  Rl:  HANDLE  POINTER  * 

s**wv*n*www«*v wwwww* { 

ENTRY 

!  SAVE  REQUESTED  ACCESS  ! 

0000  93F2  PUSH  (?R15,  R2 

!  GET  SEGMENT  HANDLE  ! 

0002  5F00  CALL  GET_HANDLE  !R1:SEG  # 

0004  0062 ' 

RETURNS : 

R0 : SUCCESS  CODE 
R4 :HANDLE  PTR 
R5: CLASS  PTR! 

0006  0B00  CP  R0 ,  #SUCCEEDED 

0008  0002 

IF  EO  !  SEGMENT  IS  KNOWN  ! 

000A  5E0E  THEN  !  VERIFY  ACCESS  ! 

000C  005E  ' 

!  SAVE  HANDLE  &  CLASS  PTR  ! 

000E  91F4  PUS HL  PR15,  RR4 

!  GET  SUBJECT'S  SAC  ! 

0010  5F00  CALL  PROCESS  CLASS  ! RETURNS: 

0012  0000* 

RR2:PR0C  CLASS! 

!  RETRIEVE  SEG  CLASS  POINTER  ! 

0014  95F0  POPL  RR0,  PR15 

!  GET  SEGMENT'S  CLASS  ! 

0016  1414  LDL  RR4,  (*R1 

!  RETRIEVE  REQUESTED  ACCESS  ! 

0018  97F1  POP  »1,  PR15 

!  SAVE  HANDLE  POINTER  ! 

001A  93F0  PUSH  PR  15,  R0 

!  CHECK  ACCESS  CLEARANCE  ! 


Ill 


001C 

001E 

0B01 

0000 

CP  Rl 

IF  EQ  ! 

0020 

0022 

5E0E 

0040' 

THEN 

0024 

0026 

5F00 

0000* 

CALL 

0028 

0B01 

CP 

002A 

0000 

IF  EO 

002C 

5E0E 

THEN 

002E 

0038' 

0030 

2100 

LD 

0032 

0021 

0034 

5E08 

ELSE 

0036 

003C  ' 

0038 

2100 

LD 

003A 

00  e2 

FI 

003C 

5E08 

ELSE  ! 

003E 

0058' 

0040 

5F00 

CALL 

0042 

0000* 

0044 

0046 

0B01 

0000 

CP 

IF  EC 

0048 

004A 

5E0E 

0054' 

THEN 

004C 

004E 

2100 

0029 

LD 

0050 

0052 

5E08 

0058' 

ELSE 

0054 

0056 

2100 

0002 

LD 

FI 

FI 


,  #WRITE_ACCESS 

WRITE  ACCESS  REQUESTED  ! 

CLASS_EQ  fRR2  .‘PROCESS  CLASS 

RR4 rSEGMENT  CLASS 
RETURNS : 

Rl:  CONDITION  CODE! 

Rl,  #FALSE 

{ACCESS  NOT  PERMITTED! 

R0,  # AC CES S _ CLASS _NOT_EQ 
JACCESS  PERMITTED! 

R0 ,  ^SUCCEEDED 

REAL  ACCESS  REQUESTED  ! 

CLASS _GE  !RR2  rPROCESS  CLASS 

RR4 rSEGMENT  CLASS 
RETURNS: 

RlrCONDITION  CODE! 

Rl,  #FALSE 

! ACCESS  NOT  PERMITTED! 

R0 ,  #ACCESS_CLASS_NOT_GE 
JACCESS  PERMITTED! 

R0,  #SUCCEEDED 


0058  97F1 
005A  5E06 
005C  0060' 

005E  97F2 

0060  9E08 
0062 


!  RETRIEVE  HANDLE  POINTER  ! 
POP  Rl,  9R15 
ELSE 

!  RESTORE  STACK  f 
POP  R2,  OR15 
FI 
RET 

END  CONVERT  AND  VERIFT 


dS 
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;e  62 


GET  HANDLE  PROCEDURE 

f  *Mt«‘*M**M*****»lM**»*,l|W**** 

’*  CONVERTS  SEGMENT  NUMBER  TO  * 


*  KST  INDEX  AND  DETERMINES  IF  * 

*  SEGMENT  IS  KNOWN.  IF  KNOWN  * 
m  POINTER  TO  SEGMENT  HANDLE  * 

*  AND  POINTER  TO  SEGMENT  CLASS* 

*  ARE  RETURNED.  * 


*  PARAMETERS :  * 

*  Rl:  SEGMENT  NUMBER  * 


m 

RETURNS : 

* 

9 

R0 : 

SUCCESS  CODE 

* 

* 

R4 : 

HANDLE  POINTER 

m 

R6: 

CLASS  POINTER 

* 

0062  0301 
0064  000A 

0066  2100 
0066  0002 
006 A  0B01 
006C  0000 

006E  5E0A 
0070  007A ' 
0072  2100 
0074  001C 
0076  5E08 
0078  0086' 
007A  0B01 
007 C  0036 

007E  5E02 
0080  0086' 
0082  2100 
0084  001C 


0086  0B00 
0088  0002 

006A  5E0S 
008 C  00BE ' 


!  CONVERT  SEGMENT  #  TO  KST  INDEX  # 
SUB  Rl,  #NR_OF_KSEGS 

!  VERIFY  KST  INDEX  ! 

LD  R0 ,  #SUCCEEDED 

CP  Rl,  #e 

IF  LS  ! INDEX  NEGATIVE! 

THEN 

LD  R0 ,  #SEGMENT_NOT_KNOWN 

ELSE  ! INDEX  POSITIVE! 

CP  Rl,  #MAX_NO_SST_ENTP.IES 

IF  GT  ! EXCEEDS  MAXIMUM  INDEX! 

THEN  ! INVALID  INDEX! 

LD  R0,  #SEGMENT_NOT_KNOWN 

FI 

FI 

CP  R0 ,  #SUCCEEDED 

IF  EO  IINDEX  VALID! 

THEN 

!  SAVE  KST  INDEX  ! 

PUSH  0R1S,  Rl 
!  GET  KST  ADDRESS  ! 


00BE  93F1 


0090  2101  LD  R1 ,  #AST  SEG  NO 

0092  0002 

0094  5F00  CALL  ITC  GET  SEG  PTR  !R1:AST  SEG  NO 

0096  0000* 

RETURNS: 

R0 : AST  ACER! 

!  RETRIEVE  AST  INDEX  #  ! 

0098  97F3  POP  R3,  C*R15 

!  CONVERT  AST  INDEX  #  TO  AST  OFFSET  ! 
009A  1902  MULT  RR2,  #SIZEOF  AST  REC 

009C  0010 

!  COMPUTE  AST  ENTRY  ADDRESS  ! 

009E  8103  ADD  R3,  R0 

!  SEE  IF  SEGMENT  IS  ANOWN  ! 

00A0  4D31  CP  AST.M  SEG  N0(R3),  #NOT  ANOWN 

00A2  000E 
00A4  00FF 

IF  EO  ! SEGMENT  NOT  ANOWN! 

00A6  5E0E  THEN 

00A8  00B2 ' 

00AA  2100  LD  R0,  #S£GMENT  NOT  ANOWN 

00AC  001C 

00AE  5E08  ELSE  {SEGMENT  ANOWN! 

00B0  00BE  * 

00B2  2100  LD  R0f  #SUCCEEDED 

00B4  0002 

!  GET  HANDLE  POINTER  ! 

00B6  7634  LLA  R4,  AST. MM  HANDLE(R3) 

00B8  0000 

!  GET  CLASS  POINTER  ! 

00BA  7635  LDA  R5,  AST. CLASS (R3) 

00BC  000A 

FI 

FI 

00BE  9E08  RET 
00C0  END  GET  HANDLE 

END  EVENT  MGR 


APPENDIX  B  -  TRAFFIC  CONTROLLER  LISTINGS 
ZS000ASM  2.02 

IOC  OBJ  CODE  STMT  SOURCE  STATEMENT 

SLISTON  $TTY 
TC  MODULE 
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TABLE  RECORD 
[NEXT  AP 

AP  PTR 

DBR  “ 

WORD 

SAC 

LONG 

PR  I 

Integer 

STATS 

INTEGER 

AFFINITY 

WORD 

VP  ID 

VP  PTR 

HANDLE 

H  ARRAf 

INSTANCE 

WORD 

VALUE 

LONG 

FILL  2 

ARRAT  [2 

J 


WORD  J 


RON  ARRAY 

rdy"array 
ap  Data 
"p'data 
Tnr_vp 
FIRST 

J 


ARRAT [VP  NR  AP  PTRJ 
ARRAI LNR~CPU  AP~PTRJ 
ARRAY [NR'PROC  AP  TABLFJ 
RECORD 

ARRAU  NR  CPU  WORDJ 
ARRAY [NR“CPU  VP  PTRJ 


EST  RSC 
[MM  HANDLE 
SIZE 
ACCESS 
IN  CORE 
CLASS 
M  SEG  NO 
ENTRY^NUM 

1 


RECORD 

H  ARRAY 

WORD 

BYTE 

BYTE 

LONG 

SHORT  INTEGER 

short“integer 


EXTERNAL 

K  LOCK 

PROCEDURE 

i ’unlock 

PROCEDURE 

SET  PREEMPT 

PROCEDURE 

SWAP  VDBR 

PROCEDURE 

IDLE” 

PROCEDURE 

RUNNING  VP 

PROCEDURE 

CREATE  INT  VEC 

PROCEDURE 

LIST  INSERT 

PROCEDURE 

ALLOCATE  MMU 

PROCEDURE 

MM  ALLOCATE 

PROCEDURE 

UPDATE  MMU  IMAGE 

PROCEDURE 

create'stack 

PROCEDURE 

MM  ADVANCE 

PROCEDURE 

mm”read  eventcount 

PROCEDURE 

G  AST  LOCK 

WORD 

PREEMPT  RET 

LABEL 
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0000 


00A0 

00A2 


0000 


0000 


0000 


$ SECTION  TC  DATA 
INTERNAL 

APT  RECOED 

[  LOCK 

RUNNING  LIST 
READY  LIST 
SLOCKED  LIST 
FILL  6  ~ 

7P 

FILL 

AP 

J 


WORD 

RUN  ARRAY 
RDY_ARKAY 
AP  PTR 
LONG 
VP  DATA 
ARRAY  [4  WORD] 
AP  DATA 


! THESE  VARIABLES  ARE  USED  DURING  TC 
INITIALIZATION  TO  S-PSCIFY  AVAILABLE 
ENTRIES  IN  THE  APT,  AND  ARE  INITIAL¬ 
IZED  Br  TC  IN  IT  IN  THIS  IMPLEMENTATION! 
NEXT_VP  WORD 
APT  ENTRY  WORD 


SSECTION  TC  LOCAL 
$  ABS  0 

! NOTE:  USEE  AS  OVERLAY  ONLY! 
ARG_LIST  RECORD 

[REG  ARRAY [ IS  WORDJ 

IC  WORD 


CPU  ID  WORD 
SAC1  LONG 
PR  II  WORD 
USR  STK  WORD 
KER"STK  WORD 
KSTl  LONG 

J 


SABS  0 

! NOTE :  USED  AS  STACK  FRAME  FOR 
STORAGE  OF  TEMPORARY  VARIABLES 
FOR  CREATE  PROCESS.! 

CREATE  "RECORD 
[APG  PTR  WORD 

DBR~NUM  WORD 

LIMITS  WORD 

SEG  ADDR  ADDRESS 
N  S"P  WORD 

J 


SABS  0 

HANDLE  VAL  RECORD 
[HIGH  LONG 
LOW  WORD 

J 
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!THE  FOLLOWING  DECLARATION  IS  UTILIZED 
*1  AS  A  STACK  FRAME  FOR  STORAGE  OF 

TEMPORARY  VARIABLES  UTILIZED  2V 
TC  ADVANCE  AND  TC  AWAIT.! 

$AES  e 

0000  TEMP  RECORD 


LRANDLE  PTR 

WORD 

EVENT  NR 

WORD 

EVENTUAL 

LONG 

ID  VP" 

WORD 

CPU  NUM 

WORD 

HANDLE  HIGH 

LONG 

HANDLE~LOW 

WORD 

SSECTION  TC  KST  DCL 
! NOTE :  KST~DECLARATI ON  IS  USED  HERE 
TO  SUPPORT  KST  INITIALIZATION  FOR 
THIS  DEMONSTRATION  ONLY.  THIS 
DECLARATION  AND  INITIALIZATION 
SHOULD  EXIST  AT  THE  SEGMENT  MANAGER 
LEVEL  AND  THUS  SHOULD  BE  REMOVED 
UPON  IMPLEMENTATION  OF  SYSTEM 
INITIALIZATION.  ! 

$ABS  0 

0000  KST  ARRAY [NR  KST  KST  RECJ 


y 


$S  ECT ION  TC  INT  PROC 

0000  TC_G£TWORK  "  PROCEDURE 

*  PROVIDES  GENERAL  MANAGE-  * 

*  MENT  Of  USER  PROCESSES  BY  * 

*  EFFECTING  PROCESS  SCEEDU-  * 

*  LING  ON  VIRTUAL  PROCESSORS* 

*  PARAMETERS:  * 

*  HI :  CURRENT  VP  ID  * 

*  R3 :  LOGICAL  CPU  #  * 

*  LOCAL  VARIABLES:  * 

*  R2:  NEXT  READY  PROCESS  * 

*  R4 :  AP  FTR  * 


0000  6132 
0002  0006' 


0004  0B02 
0006  FFFF 
0008  5E0E 
000 A  0010' 
000C  5E08 
000E  0026' 

0010  4D21 
0012  002A  ' 
0014  0001 
0016  5E0E 
0018  001E ' 
001A  5E08 
001C  0026' 


001E  6124 
0020  0020' 
0022  A142 
0024  E8EF 
0026  0B02 
0028  FFFF 
002A  5E0E 
002C  003C ' 


ENTRV 

!  FIND  FIRST  READY  PROCESS  ! 

LD  R2 ,  APT.READY_LIST(R3) 

GET_READT  AP: 

DO  “! WHILE  NOT  {END  OF  LIST  OR  READY)! 
CP  R2,  #NIL 

IF  EO  ! NO  READY  PROCESS!  THEN 
EXIT  FROM  GET_READY_AP 
FI 

C?  APT.AP. STATE(R2  )  ,  #RSADY 


IF  EO  ! PROCESS  READY!  THEN 
EXIT  FROM  GET_READY_AP 
FI 

!  GET  NEXT  AP  FROM  LIST  ! 

LD  R4 ,  APT.AP .NEXT_AP(R2) 

LD  R2 ,  R4 

OD 

CP  R2,#NIL 

IF  SO  !  IF  NO  PROCESSES  READY  !  TEEN 

!  LOAD  IDLE  PROCESS  ! 

LD  APT.RUNNING_LIST(R1 ) ,  #IDLI_FROC 


002E  4D15 
0030  0002 
0e32  DDDD 


CAIL  IDLF 
ELSE 


414334 

43036 

0036 

003A 

5F00 

0000* 

5E06 

0052' 

CAIL  IDLF 

ELSE 

!  LOAD  FIRST  READY  AP  ! 

003C 

003E 

6F12 

0002' 

LD 

APT.RUNNINC_LIST(R1  )  ,  R2 

0040 

0042 

0044 

4D25 
002A  ' 
0000 

LD 

APT.AP. STATE(R2)  ,  #RUNNING 

0046 

0048 

6F21 
002E  ' 

LD 

APT.AP.VP_ID(R2)  ,  R! 

004A 

004C 

6121 

0022' 

LD 

Rl,  APT.AP.DBR( R2 ) 

004E 

0050 

5F00 

0000* 

CALL 

FI 

SWAP_VDBR  ! ( Rl : DPR ) ! 

0052 

9E08 

RET 

0054 

END  TC 

GETWORI 

efc“54  VIRTUAL  PREEMPT_HANDIER  PROCEDURE 

*  LOADS  FIRST  READ?  A?  * 

*  IN  RESPONSE  TO  PREEMPT  * 

*  INTERRUPT  * 

$saj«V>S«>Ss<W*n**Hi««i<>**«*tvas*J*>***«  *«*»***«  ; 


00 t>4  7604 
0056  0000' 

005e  5F00 
005A  2222* 

005C  5F00 
005E  2222* 

P.lrVP  ID 
R3 :CPU  »! 

!  GET  AP  » 

0060  6112  ID  R2,  APT. RUNNING  IIST(R1^ 
0062  0002' 


0064  0B02 
0066  DDDD 
0068  5E06 
006 A  0072' 
006C  4D25 
006E  002A  ' 
0070  0001 


!  LOAD  FIRST  READ!  PROCESS  ! 

0072  5F00  CALI  TC  GETWORK  !R1:VP  ID 
0074  0000' 

R3:CPU  #! 

-  NOTE :  THIS  IS  THE  INITIAL  POINT  OF 
EXECUTION  FOP  USER  PROCESSES.! 

VIRT  PREEMPT  RETURN: 

'■**  CALL  UNLOCK  (APT~.LOCK)  **'. 

I**  RETURNS  WHEN  PROCESS  HAS  UNLOCKED  AP'7'  ! 

'.**  AND  ADVANCED  ON  THIS  EVENT  ** ! 

0076  7604  LDA  R4,  APT. LOCK 

0078  0000' 

007 A  5F00  CALL  K  UNLOCK 

007 c  0000’f 


!  IF  NOT  AN  IDLE  PROCESS,  SET  IT  TO  READY  T 
CP  R2,  #IDLE_PROC 

IF  NE  !  NOT  IDLE  !  THEN 

ID  APT  .AP .STATE (R2 )  ,  * READY 

FI 


ENTRY 

!**  CALI  WAIT_L0CK  ( APT" . LOCK )  **l 

'.**  RETURNS  WEEN  PROCESS  HAS  LOCKED  APT  ** ! 

LDA  R4,  APT. LOCK 

CALL  K_L0CK 

!  GET  RUNNING  VP  ID  ! 

CALL  RUNNING'VP  'RETURNS: 
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!  PERFORM  A  VIRTUAL  INTERRUPT  RETURN  ! 
f NOTE:  THIS  JUMP  EFFECTS  A  VIRTUAL 
I RET  INSTRUCTION.! 

007E  5E08  JP  PREEMPT  RET 
0080  0000* 

0082  END  VIRTUAL  PREEMPT  HANDLER 


GLOBAL 

SSECTION  TC  GLB  PROC 

0000  TC_IN IT  ~  “  PROCEDURE 

’*  INITIALIZES  APT  HEADER  * 

*  AND  VIRTUAL  INT  VECTOR  * 

*  PARAMETERS:  * 

*  HI:  CPU  ID  * 

*  R2 :  NR  VP  * 


0016  2104 

eeie  0000 


ENTRY 

!  NOTE:  THE  NEXT  FOUR  VALUES  ARE 
ONLY  TO  BE  INITIALIZED  ONCE.  ! 


0000 

0002 

e004 

4D05 
00A0  ' 
0000 

LD 

NEXT_VP ,  #0 

0006 

0008 

000A 

4D05 
00A2  ' 
0000 

LD 

APT_ENTRY,  #0 

000C 

000E 

0010 

4D05 
000A  ' 
FFFF 

LD 

APT.BLOCKED_LIS 

0012 

0014 

4D08 

0000' 

CLR 

APT. LOCK 

NOTE:  THE  FOILOWING  CODE  IS  INCLUDED 
ONLY  POP.  SIMULATION  OF  A  MULT IPRO CESSOR 
ENVIRONMENT.  THIS  IS  TO  INSURE  THAT  THE 
READY  LIST (S )  AND  VP  DATA  07  THE  SIMULATED 
CPU(S)  ARE  PROPERLY  INITIALIZED.  IN  AN 
ACTUAL  MULTIPROCESSOR  ENVIRONMENT,  THIS 
BLOCK  OF  CODE  SHOULD  BE  REMOVED . 

WW WJ***,>sei(t>geJ!cw *** 3gc*jgt w  v » 

LD  R4 ,  #0 


001 A  0B04 
001C  0004 

001E  5E0E 
0020  0026' 
0022  5E08 
0024  0036' 


CP  R4,  #NR_CPU*2 

IF  EO  ! ALL  LISTS  INITIALIZED! 
THEN  EXIT 
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!  INITIALIZE  READY  LISTS  AS  EMPTY  ! 
e&526  4D45  ID  APT. READY  IIST(R4),  ANIL 

0028  0006' 

002A  FFFF 

!  INITIALLY  MARK  ALL  LOGICAL  CPU'S 
AS  HAVING  1  IV.  THIS  IS  NECESSARY 
TO  INSURE  TC  ADVANCE  WILL  FUNCTION 
PROPERLY,  AS'IT  EXPECTS  EVERY  CPU 
TO  HAVE  AT  LEAST  1  VP.  ! 


002C 

4D45 

LD  APT .  VP  .  NR_VP  (P.4 )  ,  el 

002E 

0010' 

0030 

0001 

0032 

A941 

INC  R4,  *2 

0034 

E8F2 

OD 

!  END  MULTIPROCESSOR  SIMULATION  CODE. 

9  * i(c  *  * «  DC  *  « w  «  m xt  * rn  *  **  V tjt «  *  W  **  *  W  V* ** 

0036 

6F12 

LD 

APT.VP.NR_VP(R1 ) ,  R2 

0038 

0010' 

003A 

6103 

LD 

R3 ,  NEXT_VP 

003C 

00A0  ' 

003E 

6F13 

LD 

APT. VP. FIRST (Rl ) ,  R3 

004e 

0014' 

!  RECOMPUTE  NEXT  VP  VALUE  FOR  TC 

initialization^  next  logical 

CPU 

.  ! 

e042 

A125 

LD 

R5,  R2 

0044 

1904 

MULT 

RR4 ,  #2 

0046 

0002 

0048 

8153 

ADD 

R3 ,  RE 

004A 

6F03 

LD 

NEXT_VP,  RZ 

004C 

00A0  ' 

!  INITIALIZE  RUNNING  LIST  ! 

004E 

6113 

LD 

R3 ,  APT.VP.FIRST(Rl) 

0050 

0014' 

DO 

0052 

0E02 

CP 

R2,  *0 

0054 

0000 

0056 

5E0E 

IF 

EO  THEN  EXIT  FI 

0058 

005E  ' 

005A 

5E08 

005C 

006A  ' 

0e5E 

4D35 

LD 

APT . RUNNI NG_LIST ( R3  '  .  #IDLE_F3CC 

0060 

0002' 

0062 

DDDD 

0e64 

A931 

INC 

R3,  #2 

0066 

AB20 

DEC 

R2 ,  #1 

006e 

E8F4 

OD 

006A 

4D15 

LD 

APT.READT_LIST(R1U  ANIL 

006C 

0006' 

006E 

FFFF 
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0070  2101  LD  Rl,  #0 
0072  0e00 

!  ENTRY  ADDRESS  ! 

0074  7602  IDA  R2,  7 IRTtJAL_ PREEMPT  HANDLER 
0076  00S4  ' 

0078  5F00  CALL  CREATE  INT  VEC 

007 A  0000* 

! Rl : VIRTUAL  INTERRUPT  * 

R2: INTERRUPT  HANDLER  ADDRESS! 

007C  9E08  PET 

007E  END  TC  INIT 


ee?E 


CREATE  PROCESS  PROCEDURE 

I  *»WV***V*V*V*‘«‘V**‘«*V«W«« 

*  CREATES  USER  PROCESS  v 

*  DATABASES  AND  APT  * 

*  ENTRIES  * 

VV  *  W  V  90  V  W  V  W  W  V  *  V J*  V <«  V  9  * 

*  PARAMETERS:  * 

*  R14 :  ARGUMENT  PTR  * 


ENTRT 

! NOTE :  THIS  PROCEDURE  IS  A  STUB  TO  ALLOW 
PROCESS  INITIALIZATION  FOR  THIS 
DEMONSTRATION. ! 

!  ESTABLISH  STACK  FRAME  FOR  LOCAL 
VARIABLES.  ! 


007E 

030F 

SUB 

R15,  #S IZEOF  CREATE 

0080 

000A 

!  STORE  INPUT  ARGUMENT  POINTER 

0082 

6FFE 

ID 

CREATE. ARG_PTR( R15) «  R14 

0084 

0000 

!  LOCK  APT  ! 

0086 

7604 

LDA 

R4 ,  APT. LOCK 

0088 

0000' 

008A 

5F00 

CALL 

K_LOCK 

008  C 

0000* 

!  RETURNS  WHEN  APT  IS  LOCKED  ! 

!  CREATE  MMU  ENTRT  FOR  PROCESS 

0e8E 

5F00 

CALL 

ALLOCATEJMMU  ’RETURNS: 

0090 

0000* 

R0 :  DBR  * 

!  GET 

NEXT  AVAILABLE  ENTRT  IN  , 

0092 

6101 

ID 

Rl,  APT.ENTRT 

0094 

00A2' 

!  COMFUTE  APT  OFFSET  ! 

0096 

2102 

LD 

R2 ,  #S IZEOF  AP.TABLE 

0098 

0020 

009A 

8112 

ADD 

R2,  Rl 

!  SAVE  NETT  AVAILABLE  APT  ENTR' 

009C 

6F02 

LD 

APT_ENTRT,  R2 

009E 

00A2  ' 

!  CREATE  APT  ENTRT  FOR  PROCESS 

00A0 

4D15 

LD 

APT. AP. NEXT_AP( Rl ) ,  #NIL 

eeA2 

0020' 

00A4 

FFFF 

00A6 

6F10 

LD 

APT.AP.DBR(Rl),  R0 

00  A8 

0022' 

!  GET 

PROCESS  CLASS  ! 

00AA 

54  E2 

LDL 

RR2,  ARG_LIST .S AC1 (P14 ) 

00AC 

001E 

00AE 

5D12 

LDL 

APT . AP . SAC (Rl ) ,  RR2 
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00B0 

0024' 

!  GET 

PROCESS  PRIORITY  ! 

00B2 

61E2 

LD 

R2 «  ARG_LIST . PR I 1 (R 14 ) 

00B4 

0022 

00B6 

6FI2 

LD 

APT.AP.PRKR1 ),  P2 

00158 

0028' 

!  GET 

LOGICAL  CPU  #  ! 

00BA 

61  £2 

LD 

R2,  APG_LIST.CPU_ID(R14) 

00BC 

001C 

00BE 

6F12 

LD 

APT.AP.AFFI NlTYfRl ) ,  R2 

00C0 

002C  ' 

ITHREAD  IN  LIST  AND  MAKE  READ! ! 

00C2 

7623 

LDA 

R3,  APT.READY_LIST(P.2) 

00C4 

0006' 

00C6 

7604 

LDA 

R4,  APT .AP ,NEXT_AP 

00C8 

0020' 

00CA 

7605 

LDA 

R5,  APT.AP.PRI 

e0CC 

0028' 

00CE 

7606 

LDA 

R6  ,  APT. AP. STATE 

00D0 

002A  ' 

00D2 

2107 

LD 

R7,  #READY 

00D4 

0001 

00D6 

AD21 

EX 

Rl,  R2 

!  SAVE  DBR  #  ! 

00D8 

6FF0 

LD 

CREATE. D3R_NUM(R15) ,  R0 

00DA 

0002 

00DC 

5F00 

CALL 

LIST^INSERT 

00DE 

0000V 

!R2:  OBJ  ID 

R3:  LIST  HEAD  PTR 
P4:  NEXT  OBJ  PTR 
R5:  PRIORITT  PTR 
R6 :  STATE  PTR 
R7 :  STATE! 

!  UNLOCK  APT  ! 

00E0  7604  lda  R4,  apt. lock 

00E2  0000' 

00E4  5F00  CALL  K  UNLOCK 

00E6  0000» 

JCREATE  USER  STACK! 

!  RESTORE  ARGUMENT  POINTER  ! 
00E8  61FE  LD  R14,  CREATE. ARG  PTRfRISi 
00EA  0000 

00EC  61E3  LD  R3,  ARG  LIST.USR  STK(R14) 

00EE  0024 

!  SAVE  LIMITS  ! 

00F0  6FF3  LD  CREATE. LIMITS (R15  }  ,  R3 

00F2  0ee4 


00F4 

5F00 

CALL 

MM_ALLOCATE  !R3:  #  OF  BLOCKS 

00F6 

0000* 

RETURNS  r 

R2  :  START  ADDR ! 

! COMPUTE  &  SAVE  NSP! 

00F8 

A128 

LD 

R6 ,  R2 

!  ESTABLISH  INITIAL  SP  VALUE 

FOR 

USER  STACK.  ! 

00FA 

0108 

ADD 

R8 ,  * STK_OFFSET 

00FC 

00FF 

00FE 

6FF8 

LD 

CREATE. N_S_P(R15) ,  R8 

0100 

0008 

!  RESTORE  LIMITS  f 

0102 

61F4 

LD 

R4,  CREATE. LIMITS (R15) 

ei04 

0004 

0106 

AB40 

DEC 

R4  ! SEG  LIMITS ! 

!  RESTORE  DBR  ! 

0108 

61F0 

LD 

R0,  CREATE. DBR_NUM(R15) 

010A 

0002 

010C 

2101 

LD 

Rl,  #USER_STACK 

010E 

0003 

0110 

2103 

LD 

R3 ,  # WRITE  ! ATTRIBUTE ! 

0112 

0000 

0114 

5F00 

CALL 

UPDATE_MMU_IMAGE 

0116 

0000* 

!R0 :  DSP  # 

Hi:  SEGMENT  * 

R2:  SEG  ADDRESS 
R3 :  SEG  ATTRIBUTES 
R4:  SEG  LIMITS! 

! CREATE  KERNEL  STACK! 

!  RESTORE  ARGUMENT  POINTER  ! 


0118 

011A 

61FE 

0000 

LD 

R1A *  CREATE. ARG_ 

PTR (R15 ) 

011C 

eiiE 

61E3 

0026 

LD 

R3 ,  ARG_LIST . KER 

_STK(R14) 

0120 

0122 

5F00 

0000* 

CALL 

MM_ALLOCATE  !R3: 

#  OF  BLOCKS 

RETURNS 

R2 :  START  ADCR ! 

!MAKE  MMU  ENTRY! 

!  RESTORE  DBR  #  ! 


0124 

0126 

61F0 

0002 

LD 

R0  , 

CREATE. DBR_NUM(R15) 

0128 

012A 

2101 

0001 

LD 

Rl, 

#KSRNEL_STACK 

012C 

A134 

LD 

R4, 

R3 

012E 

AB40 

DEC 

R4 

0130 

0132 

2103 

0000 

LD 

R3, 

#WRITE 

!  SAVE  START  ADDRESS  ! 

12b 


0134 

6FF2 

LD 

CREATE. SEG_ADDR(R15) ,  R2 

0136 

0006 

0138 

5F00 

CALI 

UPDATE_MMU_IMAGE 

013A 

0000V 

!  R0 :  DBR  # 

Rl:  SEGMENT  # 

R2 :  SEG  ADDRESS 

R3 :  SEG  ATTRIBUTES 

P.4:  SEG  LIMITS! 

! ESTABLISH  ARGUMENTS! 

!  RESTORE  ARGUMENT  POINTER  ! 

013C 

61FE 

LD 

R14 ,  CREATE  .ARG_PTR (R15 ) 

013E 

0000 

!  RESTORE  STACK  ADDRESS  ! 

0140 

61F1 

LD 

Rl.  CREATE. SEG_ADDR(R15) 

0142 

0006 

0144 

2103 

LD 

R3,  #USER_FCW 

0146 

1800 

0148 

61E4 

LD 

R4 ,  ARG^LIST . IC (R14 ) 

014A 

001A 

!  RESTORE  INITIAL  NSP  ! 

014C 

61F5 

LD 

R5 ,  CREATE. N_S_P(R15) 

014E 

0008 

0150 

7606 

LDA 

R6,  VIRT_PREEMPT_RETURN 

0152 

0076' 

0154 

030F 

SUB 

R15,  #8 

0156 

0008 

0158 

1CF9 

IDM 

0R15 ,  R3.  #4 

015A 

0303 

!  load  argument  pointer  for 

CREATE  STACK  CALL  ! 

015C 

A1F0 

LD 

R0  ,  R15 

015E 

93F1 

PUSH 

0  P.15,  Rl 

0160 

A1E1 

LD 

Rl,  R14 

!  LOAD  INITIAL  REGISTER  VALUES  TO 

BE 

PASSED  TO  USER  PROCESS  AS 

INITIAL  PARAMETERS.  ! 

0162 

5C11 

LDM 

R2,  ARG_LIST.REG  (Rl  ’» ,  #13 

0164 

020C 

0166 

0000 

0168 

97F1 

POP 

Rl,  GR15 

016A 

5F00 

CALL 

CREATE_STACK 

016C 

0000V 

!  R0 :  ARGUMENT  PTR 

Pi:  TOP  OF  STACK 

R2-R14 :  INITIAL 

REG  STATES! 

’NOTE 

:  THE  ABOVE  INITIAL  REG  STATES 

REPRESENT  THE  INITIAL  PARAMETERS 

(VIZ 

. ,  REGISTER  CONTENTS  )  THAT  A 

USER 

PROCESS  WILL  RECEIVE  UPON 
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ei6E  010F 

0170  0008 


INITIAL  EXECUTION.  ! 

ADD  Rib,  #8  ! OV EF.LAY  PARAMETERS ! 


!  ALLOCATE  KST  ! 


0172 

2103 

LD 

R3,  #KST>IMIT 

0174 

0001 

017b 

5F00 

CALL 

MM_ALLOCATE  ! R 3 : #  OF  BLOCKS 

0178 

eeee* 

RETURNS 

R2:START  ADD?! 

!  RESTORE  DBR  ! 

ei?A 

61F0 

LD 

R0 ,  CREATE. DBR_NUM(R15) 

017C 

0002 

!  SAVE  KST  ADDRESS  ! 

017E 

6FF2 

LD 

CREATE. SEG_ADDR(R15! .  R2 

0180 

0006 

!  make 

MMU  ENTRY  FOR  KST  SEG! 

0182 

2101 

LD 

Rl,  #KST_S EG 

0184 

0002 

0186 

2103 

LD 

R3 ,  # WRITE  ! ATTRIBUTE! 

0188 

0000 

018A 

2104 

LD 

R4,  #KST_LIMIT-1 

018C 

0000 

018E 

5F00 

CALL 

UPDATE_MMU_ IMAGE 

0190 

0000* 

!R0 :  DBR  » 

Rl:  SEGMENT  # 

R2 :  SEG  ADDRESS 

R3 :  SEG  ATTRIBUTES 

R4 :  SEG  LIMITS! 

!  RESTORE  KST  ADDRESS  ! 

0192 

61F2 

LD 

R2 ,  CREATE. SEG_ADDR(R15) 

0194 

0006 

!  CREATE  INITIAL  KST  STUB  ! 

0196 

5F00 

CALL 

CREATS_KST  !R2:KST  ADD?! 

0198 

01A0  * 

!  REMOVE  TEMPORARL  VARIABLE 

STACK  FRAME.  ! 

el9A 

eieF 

ADD 

Rib,  #S I ZEOF  CREATE 

019C 

000A 

019E 

9E08 

RET 

01A0 

END  CREATE_PROCESS 
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01A0  CPEATE_KST  PROCEDURE 

f  WVVWWVWPVWW 

*  CREATES  KST  STUB  FOR  * 

*  PROCESS  MANAGEMENT  * 

*  DEMO.  INSERTS  ROOT  * 

*  ENTRY  IN  KST .  NOT  * 

*  INTENDED  TO  BE  FINAL  * 

*  PRODUCT.  * 

W  *  >K  V  >Mt  *  W  W  9  W  V  W  V  4<  V 

*  PARAMETERS:  * 

*  R2 :  KST  ADDRESS  * 


ENTRY 

! N OT E :  THIS  PROCEDURE  IS  A  STUB  USED 
FOR  INITIALIZATION  IN  THIS  IMPLEMENTATION 
ONLY.  THE  ACTUAL  INITIALIZATION  CODE 
FOR  THE  KST  WILL  RESIDE  J»T  THE  SEGMENT 
MANAGER  LEVEL  ONCE  IMPLEMENTATION  OF 
SYSTEM  INITIALIZATION  IS  EFFECTED.  ! 

!  CREATE  ROOT  ENTRY  IN  KST  ! 

01A0  1406  LDL  RR6 ,  #-l  !ROOT  HANDLE! 

01A2  FFFF 
01A4  FFFF 

01A6  5D26  LDL  KST. MM  HANDLE(R2),  RR6 
01A8  0000 

! SET  ROOT  ENTRY  *  IN  G  AST  ! 

01AA  4E25  LD  KST. MM  HANDLE [2J fR2 ) ,  40 
01AC  0004 
01AE  0000 

!  SET  ROOT  CLASSIFICATION  ! 

01B0  1406  LDL  P.R6 ,  ^SYSTEM  LOW 
01152  0000 
01B4  0000 

01B6  5D26  LDL  KST . CLASS ( R2 )  ,  RR6 
01B8  000A 

•SET  MENTOR  SEG  #! 

01BA  4C25  LDB  KST.M  SEG  N0(R2),  #0 
01BC  020E 
01BE  0000 

!  INITIALIZE  FREE  KST  ENTRIES 
FOR  DEMO.  NOT  FULL  KST! 

01C0  2101  LD  Rl,  #10 
01C2  000A 

DO 

01C4  0B01  CP  Rl,  #0 
01C6  0000 

01C8  5E0E  IF  Eg  THEN  EXIT  FI 
01CA  01D0 ' 

01CC  5E08 


01CE  01DE ' 


01D0 

0102 

ADD 

R2,  #S I ZEOF  KST_REC 

01D2 

0010 

01D4 

4C25 

LDB 

KST . M_S EG_NO( R2  )  ,  # 

0 1D6 

000E 

01D8 

FFFF 

01DA 

AB10 

DEC 

R1 

01DC 

E8F3 

OE 

01DE 

9E08 

RET 

01E0  END  CREATE  EST 
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01E0  TC  advance  procedure 

;  nVmymnvwvwniwnwiwvw 

*  EVENTCOUNT  IS  ADVANCED  BY  * 

*  INVOCATION  OF  MM  ADVANCE.  * 

*  PROCESSES  THAT  ARE  AWAITING  * 

*  THIS  EVENT  OCCURRENCE  ARE  * 

*  REMOVED  FROM  TEE  BLOCKED  LIST* 

*  AND  MADE  READY.  THE  READY  * 

*  LISTS  ARE  TEEN  CHECKED  TO  * 

*  INSURE  PROPER  SHEDULING  IS  * 

*  EFFECTED.  IF  NECESSARY  VIR-  * 

*  TUAL  PREEMPTS  ARE  SENT  TO  ALL* 

*  THOSE  VP'S  BOUND  TO  LOWER  * 

*  PRIORITY  PROCESSES  .  * 

9  jgugi  )gt vm  *  *  V  V  W #9  V  »  V  V  V  V  V  *  *  V  V  W  W  *  *  W 

*  PARAMETERS:  * 

*  Rl:  HANDLE  POINTER  * 

*  R2 :  INSTANCE  (EVENT  #)  * 

*  RETURNS:  * 

*  R0:  SUCCESS  CODE  * 


01E0  e30F 
01E2  0012 

eiE4  6FF1 
01E6  0000 
01E8  6FF2 
eiEA  eee2 

01EC  7604 
01EE  0000' 
01F0  5F00 
01F2  0000* 


01F4  5F00 
01F6  0000* 


01F8  0B00 
01FA  0002 
01FC  5E0E 
01FE  0372' 


ENTRY 

!  ESTABLISH  TEMPORARY  VARIABLE 
STACK  FRAME.  ! 

SUB  R15,  #SI ZEOF  TEMP 

!  SAVE  INPUT  ARGUMENTS  ! 

LD  TEMP.HANDLE_PTR(R15K  Rl 

LD  TEMP.EVENT_NR(R15) ,  R2 

!  LOCK  APT  ! 

LDA  P.4,  APT. LOCK 

CALL  K_LOCK 

!  RETURNS  WHEN  APT  IS  LOCKED  ! 

!  ANNOUNCE  EVENT  OCCURRENCE  BY 

INCREMENTING  EVENTCOUNT  IN  G  AST! 
CALL  MM_ADVANCE  !R1  .'HANDLE  PTR 

R2 : INSTANCE 
RETURNS  : 
R0:SUCCESS  CODE 
RR2:EVENTC0UNT! 

CP  .:c\  #SUCCEEDED 

IF  EO  THEN 
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!  SAVE  EVFNTCOUNT  ! 


0200 

5DF2 

LDL 

TEMP.EVENT_VAL(R15) ,  RR2 

0202 

0004 

!  RESTORE  INSTANCE  ! 

0204 

61F0 

LD 

R0 ,  TEMP.EVENT_NR(R16) 

0206 

0002 

!  RESTORE  HANDLE  POINTER  ! 

0208 

eiFi 

LD 

HI.  TEMP.HANDLE_PTR (R15) 

020A 

0000 

!  SAVE  HANDLE  ! 

020C 

5414 

LDL 

RR4,  PANDLE_VAL.HIGH(Rl ) 

020S 

0000 

0210 

5DF4 

LDL 

TEMP .HANDLE_HIGH ( R15 ) ,  RR4 

0212 

000C 

0214 

6114 

LD 

P4 ,  HAN  DLE_VAL . LOW ( Rl ) 

e216 

0004 

0218 

6FF4 

LD 

TEMP . FANDLE_LOW ( R15 ' ,  R4 

021 A 

0010 

!  AWAKEN  ALL  PROCESSES  AWAITING 
THIS  EVENT  OCCURRENCE  ! 

!  GET  FIRST  BLOCKED  PROCESS  ! 


021C 

021E 

6101 
000A  ' 

LD 

Rl. 

APT. BLOCKED _L 1ST 

0220 

0222 

7606 
000A  ' 

LDA 

R6 , 

APT.BLOCKED_LIST 

WAKE  UP: 

DO 

!  DETERMINE  IF  AT  END  OF  BLOCKED  LIST 


0224 

0B01 

CP 

Rl,  #NIL 

0226 

FFFF 

IF  EC 

!  NO  MORE  BLOCKED  PROCESSES  ! 

0228 

5E0E 

THEN 

EXIT  FROM  WAKE_UP 

022A 

0230' 

022C 

5E08 

022E 

02B4  ' 

FI 

!  SAVE  NEXT  ITEM  IN  LIST  ! 

0230 

6117 

LD 

R7 ,  APT.AP.NEXT_AP(R1 ) 

0232 

0020' 

!  DETERMINE  IF  PROCESS  IS  ASSOCIATED 

WITH  CURRENT  HANDLE  ! 

0234 

54F4 

LDL 

RR4,  TEMP.HANDLE_HIGH(R15) 

0236 

000C 

0238 

5014 

CPL 

RR4,  APT. AP. HANDIE(R1 ) 

023A 

0030' 

IF  EC 

!  HIGH  HANDLE  VALUE  MATCHES! 

023C 

5E0E 

THEN 

023E 

02A2  ' 

0240 

61F4 

LD 

R4 ,  TEMP. HAN DLE_ LOW (Rl 5 ) 

0242 

0010 

0244 

4B14 

CP 

P.4,  APT . AP  .HANDLE  [2]  (Rl ) 

134 


0246 

0034' 

IF  EC  !  HANDLE' 

S  MATCH  ! 

0248 

5E0E 

THEN  !  CHECK  FOR  INSTANCE  MATCH  ! 

024A 

029C  ' 

024C 

61F0 

LD  Re 

,  TEMP. EVENT  NH(RIS) 

024E 

0002 

0250 

4B10 

CP  R0 

.  APT 

.AP.INSTANCE(R1 ) 

e252 

0036' 

IF  EC  ! 

INSTANCE  MATCHES  ! 

0254 

5E0E 

THEN  JDETERmInE  IF  THIS  IS  THE 

0256 

0296' 

OCCURRENCE  THE  PROCESS 

WAITING  FOR  ! 

0258 

54F2 

LDL 

RR2 , 

TEMP.EVENT_VAL(R15) 

025A 

0004 

025C 

5012 

CPL 

RR2, 

APT . AP . VALUE ( Rl ) 

025E 

0038' 

IF  GE 

! AWAITED  EVENT  HAS  OCCURRED 

0260 

5E01 

then 

!  AWAKEN  PROCESS  ! 

0262 

0290' 

!  REMOVE 

FROM  BLOCKED  LIST  ! 

0264 

2F67 

LD 

GR6 

,  R? 

!  SAVE  LOCAL  VARIABLES  ! 

0266 

91F6 

PUSHL  0315,  RR6 

!  SET 

LIST 

THREADING  ARGUMENTS! 

0268 

6112 

LD 

•  R2, 

APT  .  AP .AFFINITY ( Rl } 

026A 

002C ' 

026C 

7623 

LDA 

R3, 

APT. READ Y_I 1ST (R2 ) 

026E 

0006' 

0270 

7604 

LEA 

R4, 

APT .AP ,NEXT_AP 

0272 

0020' 

0274 

7605 

LDA 

F5, 

APT. AP. PR  I 

0276 

0028  ' 

0278 

7606 

LDA 

R6 , 

APT. AP. STATE 

027A 

002A  ' 

027C 

2107 

LD 

37. 

WREADI 

027E 

0001 

0280 

A112 

LD 

R2 . 

Rl 

0282 

5F00 

CALL 

LIST  INSERT 

0284 

0000* 

!R2 

:  OBJ 

ID 

P.3:  LIST  HEAD  PTH 
F4:  NEXT  OBJ  PTR 
F5:  PRIORITY  PTR 
R6 :  STATE  PTR 
R7:  STATE  VALUE  ! 

!  RESTORE  LOCAL  VARIABLES  ! 
02B6  95F6  POPL  RR6 .  9R15 

0288  210B  LD  Rll,  ^REMOVED 

028A  AECD 
e28C  5E08 


ELSE  ! PROCESS  STILL  BLOCKED! 


028E  0292' 

0290  8DB8  CLR  Rll 

FI  !  END  VALUE  CHECK  ! 

0292  5E08  ELSE  IPROCESS  STILL  BLOCKED! 

0294  0298' 

0298  8DB8  CLR  Rll 

FI  !  END  INSTANCE  CHECK  ! 

0298  5E08  ELSE  ’PROCESS  STILL  BLOCKED! 

029 A  029E  ' 

029C  8DB8  CLR  Rll 

FI  !  END  HANDLE  CHECK  ! 

029E  5E08  ELSE  IPROCESS  STILL  BLOCKED! 

02A0  02A4  ' 

02A2  8DB8  CLR  Rll 

FI  !  END  HIGH  HANDLE  CHECK  ! 

!  RESET  AP  POINTER  REGISTERS  ! 

02A4  0B0B  CP  Rll,  ^REMOVED 

02A6  ABCD 

IF  NE  !  PROCESS  IS  STILL  BLOCKED  ! 

02A8  5E06  THEN 

02AA  02B0 ' 

02AC  7616  LDA  R6,  APT. AP. NEXT  AP(R1) 

02AE  0020' 

FI 

02B0  A171  LD  Rl.  R7 

02B2  E8B8  OD 

!  DETERMINE  IF  ANT  VIRTUAL  PREEMPT 
INTERRUPTS  ARE  REQUIRED  * 

02B4  8D28  CLR  R2 

PREEMPT_CEECK: 

DO 

02B6  0B02  CP  R2,  #NR_CPU  *  2 

02B8  0004 

02BA  5E0E  IF  EC  ! ALL  READY  LISTS  CHECKED!  THEN 

02BC  02C2 ' 

02BE  5E08  EXIT  FROM  PREEMPT  CHECK 

02C0  0366' 

FI 

!  CREATE  PREEMPT  VECTOR  FOR  VP'S  ! 
02C2  eD18  CLR  Rl 

DO  ! FOR  Rl=l  TO  NR  VP'S! 

02C4  A910  INC  Rl 

02C6  4B21  CP  Rl,  APT. VP. NR  VP(R2) 

02C8  0010' 

IF  GT  !  PREEMPT  VECTOR  COMPLETED  ! 
02CA  5E02  THEN  EXIT 

02CC  02D2  ' 

02CE  5E08 
02D0  02De' 

FI 

02D2  0DF9  PUSH  ORIS,  #TRUE 
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02D4  0001 
02D6  EfeF6  OD 

!  #  TO  PPEEMPT  ! 

021)8  8D38  CLR  R3 

02DA  5124  LD  R4 ,  APT. VP. NR  VP(R2^ 

02DC  0010  ' 

!  #  OF  VP'S  ! 

!  GET  FIRST  READY  PROCESS  ! 

02DE  6121  LD  Rl ,  APT. READY  LIST(R2) 

02E0  0006' 

CHECK  RDY  LIST: 

DO 

!  SEE  IF  READY  LIST  IS  EMPTY  ! 

02E2  0B01  CP  Rl,  #NIL 

02E4  FFFF 

IF  EO  ! LIST  IS  EMPTY! 

e2E6  5E0E  THEN  EXIT  FROM  CHECK  RTY_LIST 

02E8  02EE ' 

02EA  5E0e 
02EC  0324' 

FI 

02EE  4D11  CP  APT.AP.STATE(R1  ) ,  ^RUNNING 

02F0  002A ' 

02F2  0000 

IF  EO  ! PROCESS  IS  RUNNING! 

02F4  5E0E  THEN  !DON'T  PREEMPT  IT! 

02F6  030C  ' 

02F8  6115  Lr  R5 ,  APT.AP.7P  ID(Rl) 

02FA  002E  ' 

! COMPUTE  LOCATION  IN  PREEMPT  VECTOP! 
02FC  4325  SUE  R5,  APT .VP . FIRST (R2  ) 

02FE  0014' 

0300  74F6  LEA  R6 ,  Rl5(R5) 

0302  0500 

0304  0D65  LD  (?R6,  #FALSE 

0306  0000 

0308  5E08  ELSE  !  PREEMPT  IT  ! 

030 A  030E ' 

030C  A930  INC  R3 

FI 

030E  AE40  DEC  R4 

0310  0B04  CP  R4 ,  #0 

0312  0000 

IF  EO  ! ALL  VP'S  VERIFIED! 

0314  5E0E  TEEN 

0316  031C ' 

0318  5Eee  EXIT  FROM  CHECK  RDY  LIST 

031 A  0324' 

FI 

!  GET  NEXT  AP  IN  READY  LIST  ! 

031C  6110  LD  R0,  APT. AP. NEXT  AP(Rl) 
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031E 

0020  ' 

0320 

A101 

LD  Rl,  P0 

0322 

E8DF 

OD  ! END  CHECK  RDY  LIST! 

!  SET  NECESSARY  PREEMPTS  ! 

0324 

0326 

6124 

0010' 

LD  R4 ,  APT.VP.NR_VP(R2) 

0323 

032A 

6121 

0014' 

LD  El,  APT. VP. FIRST (R2) 

SEND  PREEMPT: 

DO 

032C 

97F0 

POP  R0 ,  0R15 

!  CHECK  TEMPLATE  ! 

032E 

0330 

0500 

0001 

CP  B0,  #TRUE 

IF  Eg  ! C AN  EE  PREEMPTED! 

0332 

0334 

5E0E 

0350' 

THEN 

0336 

0338 

0B03 

0000 

CP  R3,  #0 

IF  GT  IPREEMPTS  REQUIRED! 

033A 

033C 

5E02 

0350' 

THEN  ! PREEMPT  IT! 

!  SAVE  ARGUMENTS! 

033E 

93F1 

PUSH  OR16.  R1 

0340 

91F2 

PUSHL  (?E15,  RR2 

0342 

93F4 

PUSH  yP.15 ,  R4 

0344 

5F00 

CALL  SET.PREEMPT 

0346 

0000» 

! PI :  VP  ID! 

!  RESTORE  ARGUMENTS  ! 

* 

0348 

97F4 

POP  R4,  GP-15 

034 A 

95F2 

POPL  RR2,  r*Sl5 

034C 

97F1 

POP  Rl,  G»R15 

034S 

AB30 

DEC  R3 

FI 

FI 

0350 

A911 

INC  Rl,  H2 

0352 

A  540 

DEC  R4 

0354 

0356 

0Be4 

0000 

CP  RA,  «0 

IF  EO  ! STACK  RESTORED! 

t 

03se 

5E0E 

THEN 

i 

035A 

0360' 

j 

035C 

5E08 

EXIT 

i 

035E 

0362' 

FI 

i 

0360 

E8E5 

OD  ! END  SEND  PREEMPT! 

!  CHECK  NfiXT~READY  LIST  ! 

i 

0362 

A921 

INC  R2,  #2 

j 

0364  E8A8 


OD  ! END  PREEMPT  CHECK! 
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J 


!  UNLOCK  APT  ! 


0366 

7604 

LDA 

R4 ,  APT. LOCK 

0368 

0000' 

036  A 

5F00 

CALL 

K_UNLOCK 

036C 

0000* 

l  RESTORE  SUCCESS  CODE 

036E 

2100 

ID 

R0 ,  #SUCCEEDED 

0370 

0002 

FI 

!  RESTORE  STACK  ! 

0372 

010F 

ArD 

R15,  #S  I  ZEOF  TSt*P 

0374 

0012 

0376 

9E09 

RET 

e378 

END  TC 

ADVANCE 

0378  tc  await  procedure 

*  CHECKS  USER  SPECIFIED  VALUE  *•* 

*  AGAINST  CURRENT  EVENTCOUNT  * 

*  VALUE.  IF  USER  VALUE  IS  LESS  * 

*  THAN  OP  EQUAL  EVENTCOUNT  THEN5" 

*  CONTROL  IS  RETURNED  TO  USER.  * 

*  ELSE  USER  IS  BLOCKED  UNTIL  * 

*  EVENT  OCCURRENCE.  * 

W'V  WWW  WM  V  WJ?  WWW  WWW 

*  PARAMETERS:  * 

*  Rl:  HANDLE  POINTER  * 

*  R2  :  INSTANCE  (EVENT  *)  * 

v  R®4:  SPECIFIED  VALUE  * 

*  RETURNS :  * 

*  ?0 :  SUCCESS  CODE  * 

ENTRT 

!  ESTABLISH  STACK  FRAME  FOR 
TEMPORARY  VARIABLES.  * 

0378  030F  SUB  R15,  4SIZE0F  TEMP 
037 A  0012 

!  SAVE  INPUT  PARAMETERS  ! 

037C  6FF1  LD  TEMP. HANDLE  PTR(Rl5),  Rl 

037E  0000 

e380  6FF2  LD  TEMP.  EVENT  NR  (RISK  R2 
03e2  0002 

0384  5DF4  DDL  TEMP. EVENT  VAI(R15),  RR4 
0386  0004 

!  LOCK  APT  ! 

03e8  7604  LDA  R4.  APT. LOCK 
038 A  0000' 

038C  5F00  CALL  K_L0CK 

038E  0000* 

!  RETURNS  WHEN  APT  IS  LOCKED  ! 

!  GET  CURRENT  EVENTCOUNT  ! 

0390  5F00  CALL  MM_READ_EVENTC OUNT 

in qv  pl'i/i/v 

! Rl : HANDLE  POINTER 
R2: INSTANCE 
RETURNS  : 

R0 : SUCCES S  CODE 
RR4 :  EVENTCOUNT! 

0394  0B00  CP  R0 •  #SUCCEEDED 

0396  0002 

0398  5E0E  IF  SC  THEN 

039 A  0440' 

!  DETERMINE  IF  REQUESTED  EVENT 
HAS  OCCURRED  ! 
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039C  54F6 
039E  0004 
03A0  9046 

03A2  5E02 
03A4  0440' 

03A6  5F00 
03A6  0000* 


03AA  6FF1 
03AC  0008 
03AE  6FF3 
03B0  000A 
03B2  6118 
03B4  0002' 

e3B6  61F2 
03B8  0002 
03BA  61F1 
e3BC  0000 

03BE  5414 
e3C0  0000 
03C2  5D84 
03C4  0030' 
0  3C6  6114 
03C8  0004 
03CA  6F84 
03CC  0034' 
03CE  6F92 
03D0  0036' 
03D2  54F6 
03D4  0004 
03D6  5De6 
03D8  0038' 

03DA  6181 
e3CC  002C  ' 
03DE  6112 
03E0  00.06' 


03E2  eB82 

03E4  5E0E 
03S6  03F4 ' 
03E8  6183 
03EA  0020' 


LDL  RR6,  TEMP .EVENT_VAL(Rl5) 

CPL  RR6 ,  RR4 

IF  GT  ! EVENT  HAS  NOT  OCCURRED! 
THEN  ! BLOCK  PROCESS! 

!  IDENTIFY  PROCESS  ! 

CALL  RUNNI NG_V?  {RETURNS : 

Rl  :7P  ID 
R3  :CFU  ff\ 

!  SAVE  RETURN  VARIABLES  ! 

ID  TEMP . I B_VP( R15 ) ,  Rl 

LD  TEMP . CPU_NUM( Rl5 ) ,  R3 

LD  R8 ,  APT.RUNNING_LIST (Rl ) 

!  RESTORE  REMAINING  ARGUMENTS  ! 

LD  R2 ,  TEMP.EVENT_NR(R15) 

LD  Rl,  TEMP.HANDLE_PTR(R15) 

!  SAVE  EVENT  TATA  ! 

LDL  RR4,  HANDLE_VAL.HIGH(Rl) 

LDL  APT. AP. HANDLE ( R8 ) ,  RR4 

LD  R4,  HANDLE_VAL.LOW(Rl > 

LD  APT. AP. HANDLE [2J (R8) ,  R4 

LD  APT. AP.lNSTANCE(Re),  R2 

LDL  RR6,  TEMP.EVSNT_VA1(R15> 

LDL  APT.AP.VALUE(RS),  RR6 

!  REMOVE  PROCESS  FROM  READY  LIST  ' 
LD  Rl,  APT. AP. AFFINITY (RS ) 

LD  R2,  APT.READY_LIST(R1  ) 

!  SEE  IF  PROCESS  IS  FIRST 
ENTRY  IN  READY  LIST  ! 

CP  R2 ,  Rg 

IF  EC  ! INSERT  NEW  READY  LIST  E  1 
THEN 

LD  R3 .  APT. AP. NEXT  AP(R8' 
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03EC 

6F13 

LB 

APT .REaDY_LI?T(P,1 ) ,  R3 

03ES 

0006 

03F0 

5E08 

ELSE 

'DELETE  FROM  LIST  BODY! 

03F2 

040E  ' 

DO 

03F4 

6123 

ID 

R3 .  APT.AP.NEXT_AP(R2^ 

03F6 

0020' 

03F8 

SE83 

CP 

R3 ,  R8 

IF 

EC  'FOUND  ITEM  IN  LIST! 

03FA 

5E0E 

THEN 

03FC 

040A  ' 

03FE 

6183 

LD  R3 ,  APT . AP .  NSXT.AP ( R8 ) 

0400 

0020  ' 

0402 

6F23 

LD  APT.AP .NEXT_AP(R2) ,  R3 

0404 

0020' 

0406 

5E08 

EXIT 

0408 

040E ' 

FI 

040A 

A132 

LI 

R2,  R3 

040C 

E8F3 

OE 

FI 

JTHREAD  PROCESS  IN  f LOCKED  LIST! 

040E 

A182 

LD 

R2,  R8 

0410 

7603 

LDA 

R3  ,  APT . BLOCXED_LIST 

0412 

000A  ' 

0414 

7604 

LDA 

R4,  APT.AP. NEXT. AP 

0416 

0020' 

0418 

7606 

LDA 

R6,  APT.AP. PR I 

041 A 

0028  ' 

041C 

7606 

LDA 

R6 ,  APT.AP. STATE 

041E 

002 A' 

0420 

2107 

LD 

R7,  ^BLOCKED 

0422 

0002 

0424 

5F00 

CALL 

LIST.I NSERT  !R2:0£J  ID 

0426 

0000» 

R3:LIST  HEAD  PT 
P.4:NSXT  OBJ  FTP 
RbiPRIORITY  PTR 
R6 :STATE  PTR 
R7:STATS  ! 

!  GET 

CURRENT  VP  ID  ! 

0428 

61F1 

LD 

Rl,  TEMP . ID_VP (R15  ) 

042 A 

0008 

042C 

61F3 

LD 

R3,  TEMP.CPU_NUM(R15) 

042E 

000A 

!  SCHEDULE  FIRST  READY  PROCESS  ! 

0430 

5F00 

CALL 

TC.GETWORK  !R1:VP_ID 

0432 

0000' 

0434  7604 


!  UNLOCK  APT  ! 

LDA  P.4,  APT. LOCK 


R3:CPU  »! 


£436 

0000' 

0438 

5F00 

CALL  K_UN  LOCK 

243A 

0000s*6 

!  RESTORE  SUCCESS  COLE 

043C 

2100 

LD  F0  ,  #SUCCEEDED 

043E 

0002 

FI 

FI 

!  RESTORE  STACK  ? 

0440 

010F 

ADD  R15 ,  #SIZEOF  TEMP 

0442 

0012 

2444 

9E08 

RET 

0446 

END  TC_AWAlT 
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0446  PROCESS  CLASS  PROCEDURE 

f  VW W *»?M WW  W>W  W  WM*** W 

*  READS  SECURITY  ACCESS  * 

*  CLASS  OE  CURRENT  PROCESS  * 

*  IN  APT.  CALLED  B*  SEG  * 

*  MGR  AND  EVENT  MGR  * 

*w  w  w  w  vw  v  ww  vw 

*  LOCAL  VARIABLES:  * 

*  Hi:  VP  IE  * 

*  R5 :  PROCESS  ID  * 

WWW  WWWWWW  W  W  W  W***? 

*  RETURNS:  * 

*  RR2 :  PROCESS  S  AC  * 

W»WW VWW VW WM VW  WWWW  J 


ENTRY 

0446 

7604 

LDA 

R4, APT. LOCK 

0448 

0000  ' 

044A 

5F00 

CALL 

K_L0CK  !R4:  '’APT  .LOCK  ! 

044C 

0000* 

044E 

5F00 

CALL 

RUNN ING_VP  ’RETURNS: 

e4b0 

000e* 

R1 : VP  ID 

R3  :C?U  #! 

0452 

6115 

LD 

R5, APT . RUNNlNG_LIST (R1 ) 

0464 

0002  ' 

0456 

5452 

ILL 

RR2 , APT . A? . SAC ( Rb ) 

0458 

0024' 

!  UNLOCK  APT  ! 

045A 

7604 

IDA 

R4,  APT. LOCK 

045C 

0000' 

046E 

5F00 

CALL 

K_UNL0CK 

0460 

0000* 

0462 

9E08 

RET 

V 464  End  PROCESS  CLASS 


0464  GET  DBR  NUMBER  PROCEEURE 

|  999  99  9999999999999  «*<>*>!<  9  9999V99  999 

*  OBTAINS  DBR  NUMBER  PROM  APT  * 

*  FOR  THE  CURRENT  PROCESS.  * 

*  CALLED  Bv  SEGMENT  MANAGER  * 

999  99999999  9999999999  99  V«  99 

*  LOCAL  VARIABLES:  * 

*  PI:  VP  ID  * 

*  R5 :  PROCESS  ID  * 

999999999999999999999999999999999 

»  RETURNS:  * 

*  Rl:  DBP  NUMBER  * 

If9999**9v*v**vmv«?mmv*9*«v9  > 

ENTRV 

! NOTE :  DBR  *  IS  ONLY  VALID  WHILE  PPOCE 
IS  LOADED.  THIS  IS  NO  PROBLEM  IN  SAS 
AS  ALL  PROCESSES  REMAIN  LOADED.  IN  A 
MORE  GENERAL  CASS,  THE  DBR  *  COULD  ONLY 
PE  ASSUMED  CORRECT  WHILE  THE  APT  IS  LOCKET 


£464 

0466 

7604- 
0000  ' 

LDA 

R4, APT. LOCK 

046e 

e46A 

5Fe0 

0000* 

CALL 

K_10CK  !  P.4:  ~APT.  LOCK! 

046C 

5F00 

CALL 

RUNN ING_VP  ! RETURNS: 

046E 

0000* 

Rl : VP  ID 

R3 : CPU  *! 

0470 

0472 

6115 

0002' 

LD 

R5, APT. RUNNING  LIST(RH 

0474 

0476 

6151 

0022' 

LD  Rl , APT . AP . DBR ( 35  ) 

!  UNLOCK  APT  ! 

0478 
047  A 

7604 

0000' 

LDA 

R4,  APT. LOCK 

047C 

047E 

5F00 

0000* 

CALL 

KJJNLOCK 

0^80 

9E08 

RET 

0482 

END  GET_DBR_ NUMBER 

END  TC 
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t/2  UJ 


APPENDIX  C  -  DISTRIBUTED  MEMOR I  MANAGER  LISTINGS 


Z8000ASM  2.02 

IOC  OBJ  CODE  STMT  SOURCE  STATEMENT 


$ LISTON  STT^ 
DIST_MM  MODULE 

CONSTANT 

C?EATE_CODE 
DEL£TS_CODE 
ACTI VATE_CODE 
DEACTIVATE  CODE 
SWAP  IN  CODE 
S¥AP~OUT  CODE 
NR  CPU 

NR~KST_ENTRY 
MAX_SEG_S I ZE 
MAX_DBR  NO 
SST_SEG-NO 

nr_of_ksegs 

ELOCK_S IZE 
MEM  AVAIL 
G  AST  LIMIT 
I NST ANCE1 
INSTANCE2 
INVALID  INSTANCE 
SUCCEEDED 

TYPE 

E_ARflAY 
COM  MSG 
ADDRESS 

G  AST  REC 

Tunioue_id 

GLOEAL_ADDR 
P  L_ASTE  NO 
FLAG 

PAR  ASTE 
NR  ACTIVE 

no"act  dep 

SIZE1 
PG  TBL 
ALIAS  TBL 
SEQUENCER 
EVENT1 
EVENT 2 

J 


=  50 
=  51 
=  52 
=  53 
=  54 
=  55 
=  2 
=  54 
=  12  = 

=  4 
=  2 
=  10 
-  U 

=  *F00 
=  10 
=  1 
=  2 

*  95 

*  2 


ARRAY  [3  WORDJ 
ARRAT  [16  BYTEJ 
WORD 

RECORD 

LONG 

ADDRESS 

WORD 

WOPD 

WORD 

WORD 

BYTE 

BYTE 

ADDRESS 

ADDRESS 

LONG 

LONG 

LONG 
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S  EG_AFRAY  ARRAY  [MAX_SEG_SIZE  BYTE] 

SSECTION  D  MM  DATA 

GLOBAL 

MM_CPTT_T3L  ARRAY  [NR_CPU  MM_7P_IDJ 

SSECTION  AVAIL  MEM 

INTERNAL 

!  NOTE:  MEM  POOL  IS  LOCATED  IN 
CPU  LOCAL~MEMORY.  ! 

MEM_?OOL  ARRAY  [MEM_AV AIL  BYTE] 

GLOBAL 

!  NOTE:  NEXT  BLOCK  IS  USED  IN  THE  MM  ALLOCATE 
STUB  AS  AN-0FISET  POINTER  INTO  TH£~£LOCK 
Of  ALLOCATABIE  MEMORY.  IT  IS  INITIALIZED 
IN  BOOTSTRAP  LOADER.  ! 

NEXT  BLOCK  WORD 

SSECTION  MSG  FRAME  DCL 
INTERNAL 

!NOTE:  THESE  RECORDS  ARE  "OVERLAYS"  OR  "FRAMES"  USED 
TO  DEFINE  MESSAGE  FORMATS.  NO  MEMORY  IS  ALI OCATED  ! 

SABS  0 

CREATE  MSG  RECORD  fCR  CODE  WORE 

OE“MM_HANDLE  H_ ARRAY 
CE_fiNTRY_NO  SHORT_I NTEGER 
C£  FILL  '  EYTE 
CK~SIZS  WORE 

CE'CLASS  LONG] 

SABS  0 

DELSTE_MSG  RECORD  [DE  CODE  WORD 

DS-MM  HANDLE  H  ARRAY 
DElENTRY  NO  SFORT_I NTEGER 
DE_F ILL  APRAYT?  BYTEJ  ] 

SABS  0 

ACTIVATE  MSG  RECORD  [ACT  CODE  WORD 

A~DBR_NO  WORr 

A~ MM  HANDLE  H  ARRAY 
a"ENTRY_NO  SHORT  INTEGER 
A_SEGMENT  NO  SHORT~lNTEGER 
A~FILL  "  LONG  1  ** 


sabs  0 


oeoo 

DEACT I7ATE_VSG 

RECORD 

[DEACT  CODE 

WORD 

D  DBR  NO 

WORD 

D~VV  HANDLE 

H  ARRAY 

d'fill 

ARRAY  [3 

WORD!  J 

SA3S  0 

0000 

SWAP_IN_MSG 

RECORD 

rs  IN  CODE 

WORD 

SI  VV  HANDLE 

H  ARRAY 

5  I~D£F  NO 

WORD 

SI  access  aute  byte 

SI  Fit  LI 

BVTE 

SI'FILL 

ARRAY [Z 

X  CRD J  J 

SABS  0 

0000 

SWAP_OTJ?_MSG 

RECORD 

[S  OUT  CODE 

WORD 

SO  DBF.  NO 

WORD 

SO“*V  HANDLE 

H  ARRAY 

SO  FILL 

ARRAY [3 

WORD]  J 

$  ASS  0 

0000 

R£T_SUC_COD£ 

RECORD  [SUC  CODE 

BYTE 

SC  FILL 

J 

ARRAY [It 

BVTEJ 

SABS  0 

0000 

p_activate_arg 

RECORD 

[R  SUC  CODE 

3VTE 

R~FILL 

BYTE 

R’VV  HANDLE 

H  ARRAY 

R "CLASS 

LONG 

P.'SIZS 

WORD 

fi'FlLIl 

WORT] 

SABS  0 

0000  MV  HANDLE  RECORD 

[ID  LONG 

ENTRV  NO  WORD 

J 


je&fsr. 


EXTERNAL 


G  AST  LOCK 


tf  ORD 


G_AST  ARRAr  lG_AST_Lll*I7  G_AST_RECJ 


K_LOCK 
K  UNLOCK 


PROCEDURE 

PROCEDURE 


GET  CPU  NO  PROCEDURE 


SIGNAL 


¥  A I T 


PROCEDURE 

PROCEDURE 


GLOBAL 

$SECTION  D_MM_PROC 


0fe3fe>fe9  MM  CREATE  ENTRY  FROCEDURE 

I  vw  V  V  W  WJ?  Wi?  VW 


296 

INTERFACE  BETWEEN  SEG  MGR 

>96 

396 

(CREATE  SEG  PROCEDURE )  AND 

3Q6 

*6 

MMGR  PROCESS  (CREATE  ENTRY 

3* 

3* 

PROCEDURE).  ARRANGES~AND 

396 

PERFORMS  IPC. 

396 

V 

REGISTER  USE: 

396 

396 

PARAMETERS 

396 

V 

R0  :  SUCCESS  CODE  (RET) 

3? 

596 

RlrhPTR  (INPUT) 

V 

V 

R2 : ENTRV  NO  (INPUT) 

3J6 

R3JSIZE  IlNPUT) 

V 

ace 

RR4  :CLASS  (INPUT) 

396 

396 

LOCAL  USE 

396 

V 

Rb : MM  HANDLE  ARRAY  ENTR v 

3* 

396 

Re^COM  MSGBUF 

V 

396 

R13:"C0M  MSGBUF 

3J6 

WV  W  vsgcw  wvw  WW1**  w  w  w  wttw  W  1 

ENTRY 

! USE  STACK  FOR  MESSAGE ! 

0000  030F  SUB  R15,#SIZE0?  COM_MSG 
0002  0010 

0004  AlFD  LD  R13 ,R1 5  !  ~COM_MSGBUF  ! 

! F ILL  COM  MSC-BUF  (LOAD  MESSAGE).  CREATE  MSG 
FRAME  IS  BASED  AT  ADDRESS  ZERO.  IT  IS 
OVERLAID  ONTO  COM  MSGBUF  FRAME  £T  INDEXING 
EACH  ENTRY  (I.E.  ADDING  TO  EACH  ENTRY)  THE 
BASE  ADDRESS  OF  COM  "SGBUF! 


000  b 

4DD5 

LD 

0008 

0000 

000  A 

0032 

000C 

3116 

LD 

000E 

0000 

0010 

5FD6 

LD 

0012 

0002 

0014 

3116 

LD 

0016 

0002 

00ie 

6FD6 

LD 

00 1A 

0004 

001C 

3116 

LD 

001E 

0004 

0020 

6FD6 

LD 

0022 

0006 

0024 

6FD2 

LD 

CREATE_MSG.CR_C0DE(R13) ,#CREATE_CODE 

Rb,Rl(#0)  'INDEX  TO  MM_HANDLE  ENTRY! 
CREATE_MSG.CE_MM_HANDLE[0j  (R13) ,R6 
Rb, R1 (#2) 

CR£ATE_MSG.CS_MM_HANDLEll] (R13) ,R6 
R  b , R 1 ( #4 ) 

CREATE_MSG.CE_MM_HANDLE12J (R13) , Rb 
CREATE_MSG . CE_ENTRY_NO ( R13 ) .R2 


0026 

0006 

0026 

6ED4 

LDL 

CR3ATE_MSG. 

002A 

000C 

002C 

6FD3 

LD 

CR£ATE_MSG. 

002  £ 

000A 

0030 

AIDS 

ID 

R8.R13 

0032 

5F00 

CALL 

PEvFOFf*_IPC 

0e34 

016C  * 

! RETRIEVE  SUCCESS 

0036 

8D0S 

CLR 

R0 

ze36 

60D8 

LDB 

RL0  *RET_SUC 

003A 

0000 

003C 

010F 

ADD 

R15 , #S IZ  EOF 

e03S 

0010 

0040 

9E08 

RET 

0042 

END 

MM_CREATE_SNTRT 

0042 


MM  DELETE  ENTRY  PROCEDURE 

<  w wvmm ww v« m« 

*  interface  retween  seg  mgr  * 

*  (DELETE  SEG  PROCEDURE)  AND  * 

*  MMGR  (DELETE  ENTRY  PROCEDURE ) .* 

*  ARRANGES  AND'PERFORMS  IPC.  * 

9 9  9  9 9 9  9  9 9  99  9  9  V  V  W  V  *  V  ««  9  V  V *  V  *  V  V  *  9  9 


*  PSGISTER  USE:  * 

*  PARAMETERS  * 

*  R0 :SUCCESS  CODE(RET)  * 

«  Rl : HPTR ( INPUT  )  * 

*  R2 : ENTRY  NO(INPUT)  * 

*  LOCAL  USE~  * 

*  R6 : MM  HANDLE  ARRAY  ENTRY  * 

*  R8:~cCM_MSGBUF  * 

*  R13:'’C0M  MSGBUF  * 


fWW*HDVMv5l»#VWlil WW* 9WV9W9 W  ? 

ENTRY 


!  USE 

STACK  FOR  MESSAGE! 

0042 

030F 

SUB 

R15,#SIZE0F  C0M_MSG 

0044 

0010 

0046 

AlFD 

LD 

R13.R15  !  ''COM_MSGBUF  ! 

!FILL  COM  MSGBUF  (LOAD  MESSAGE).  DfiLETE_MSG  FRAME 
IS  £ASED~AT  ADDRESS  ZERO.  IT  IS  OVERLAID  ONTO 
COM  MSGBUF  F»AMJS  BY  INDEXING  EACH  ENTRY  U.E.  ADD¬ 
ING  TO  EACH  ENTRY)  THE  BASE  ADDRESS  Oj  COM_MSG£UF! 
0048  4DD5  LD  DELETE  MSG.DE  C0DE(R13^,#LELETE  CODE 

004A  0000 
004C  0033 

004E  3116  LD  R6» Rl(*fc)  !INDEX  TO  MM  HANDLE  ENTRY! 

0050  0000 

0052  6FD6  ID  DELETE  MSG.DE  MM  HANDLE (0 ] (R 13 )  ,R6 

0054  0002 

0056  3116  LD  R6,R1(#2) 

0058  0002 

005A  6FD6  LD  DELETE  MSG.DE  MM  HANDLE  UJ  (P.13  ).  R6 

005C  0004 

005E  3116  LD  H6,P1(*4) 

0060  0004 

0062  6FD6  LD  DELETE  MSG.DE  MM  HANDLE [2j  (R13 )  ,R6 

0064  0006 

0066  6FD2  LD  DELSTE_MSG . DE_ENTRY_NO ( R13) ,32 

006e  0006 

00bA  AIDS  LD  R8,R13 

006C  5F00  CALL  PERFORM  IPC  !Rfc:  ''COM  MSGiUF ! 

006E  018C' 

! RETR IEVE  SUCCESS  CODE  FROM  RETURNED  MESSAGE! 
0070  0D06  CLR  R0 

0072  60DB  LDB  RL0 , RET_SUC_CODE  .SUC.CODE ( R13 ) 

0074  0000 

0076  ei0F  ADD  R15 ,#S IZEOF  COM  MSG  JRESTORE  STACK  STATE! 

0078  0010 

007 A  9E08  RET 

007C  END  MM  DELETE  ENTRY 
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ee?c  MM  activate  procedure 

’*  INTERFACE  BETWEEN  SEG  MGR  * 

*  (MAKE  KNOWN  PROCEDURE  ^  AND  1(1 

*  MMGR  "  (ACTIVATE  PROCEDURE).  * 

*  ARRANGES  AND  PERFORMS  IPC .  v 


*  REGISTER  USE:  * 

*  PARAMETERS  * 

*  Rl:DRR  NO ( INPUT  )  * 

*  R2 : HPTR ( INPUT  5  * 

*  R3:£NTRY  NO  * 

*  R4 : SEGMENT  NO  * 

*  R12:RET_HANDLE_PTR  * 

*  LOCAL  USE  v 

*  R8  :"'COM_MSGiUF  * 

*  R13:"C0M  MSGBUE  * 

*  RETURNS:  "  * 

*  R0  :SUCCESS  CODE  * 

*  PR2 :CLASS  * 

*  R4:SIZE  * 


*«9  99V*9W«****V4 * 

ENTRT 

! USE  STACK  FOR  MESSAGE! 

007C  030F  SUB  R15,#SIZE0F  COM  MSG 

007E  00145 

45080  A1FD  LD  P13.R15  !  "COM_MSGBUE  ! 

!  SAVE  RETURN  HANDLE  POINTER  ! 

0082  93FC  PUSH  PR15,  R12 

!FILL  COM_MSGBUF  (LOAD  MESSAGE).  ACTIVATE  MSG  FRAME 
IS  BASED  AT  ADDRESS  ZERO.  IT  IS  OVEELAID'ONTO 
COM_MSGBUI  FRAME  BT  INDEXING  EACH  ENTR-7  (I.E.  ADD¬ 
ING  TO  EACH  ENTRY)  THE  BASE  ADDRESS  CF  COM  MSGBUF! 
0084  4DDb  ID  ACTIVATE  MSG. ACT_C0DE(R13' .^ACTIVATE  CODE 

0086  0000 
0068  0034 

008A  6FD1  LD  ACTIVATE  MSG. A  DER  N0(R13),fll 

008C  0002 

008E  3126  LD  R6,R2(#0) 

0090  0000 

0092  6FD6  LD  ACTIVATE  MSG. A  MM  HANDLE  [ 0j  ( R 13 5 ,R6 

0094  0004 

0096  3126  LD  R6,R2(#2) 

0098  0002 

009 A  6FD6  LD  ACTIVATE  MSG. A  MM  HANDLE UJ ( Rl3 ) ,R6 

009C  0006 

009E  3126  LD  R6,R2(*4) 

00A0  0004 

00A2  6FD6  LD  ACTIVATE  MSG. A  MM  HANDLE L2J ( 313) ,R6 
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00A4  000s 

00A6  6EDB  LDB  ACTI VATE_MSG . A_ENTR Y_NO ( R12 ) ,RL3 

00A8  000A 

00AA  6ErC  LDB  ACTIVATE  MSG. A  SEGMENT  N0(H13'.  .214 
00AC  000B 

00AE  AIDS  LD  R6.P13 

00B0  5F00  CALL  PERFORM  IPC  !(Rt  :"COM  MSGBUF ! 

00B2  018C  * 

!  RESTORE  RETURN  HANDLE  POINTER  ! 

00B4  97FC  POP  R12,  @215 

!  UPDATE  MM_HANDLE  ENTRY  ! 

00B6  54D6  LDL  RR6,  R  ACTI VATS_ARG . R  MM  HANDLE ( R12 ) 

00BS  0002 

00iA  5DC6  LDL  MM  HANDLE. ID( R12 )  ,  RR6 
00BC  0000 

00BE  6 1D6  LD  R6,R  ACTIV ATE_ARG  .R_*M  HANDLE  1 2J  ( R13 ) 

00C0  0006 

00C2  6FC6  LD  MM  HANDLE. ENTRY  NO(RISJ),  R6 

00C4  0004 

! RETRIEVE  OTHER  RETURN  ARGUMENTS! 

00C6  SD08  CL®  R0 

00C8  60D8  LDB  RL0.R  ACTIVATE  ARG.R  SUC  C0DE(R12) 

00C A  0000 

00CC  54D2  LDL  RR2,R  ACTIVATE  ARG.R  CLASS(R13) 

00CE  0008 

00D0  61D4  LD  R4,R  ACTIVATE  ARG.R  SIZE(F13) 

00D2  000C 

00D4  010F  ADD  R15,#S IZSOF  COM  MSG  JRESTOflE  STACK  STATE! 

00D6  0010 

00D8  9E08  RET 

00DA  END  MM  ACTIVATE 
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00DA  MM  DEACTIVATE  FROCEDUKE 

*  INTERFACE  BETWEEN  SEG  MGR  * 

*  (TERMINATE  PROCEDURE )  AND  * 

*  MMGR  (DEACTIVATE  PROCEDURE).  * 

*  ARRANGES  AND  PERFORMS  IPC .  * 

9  W  « W  W  W  «  *  W  9  W  igt  W  «  «  9  9  «  V  «  W  «  «  W 


*  REGISTER  USE:  * 

181  PARAMETERS  * 

*  R0 : SUCCESS  COD£(RET  ^  * 

*  R1 :DBR  NO(lNPUT)  * 

*  R2:HPTR(INPUT)  * 

*  LOCAL  USE  * 

*  R6 :MM  HANDLE  ARRAY  ENTRY  * 

*  R8 : ~COM_MSGBUF  * 

*  R13:~C0M  MSGBUF  * 


ENTRY 

.'USE  STACK  FOR  MESSAGE! 

00 DA  030F  SUB  R15 ,#S IZEOF  COM  MSG 
00DC  0010 

00DE  A1FD  LD  Hi?, Rib  !  "CO.M_MSGBUF  ! 

!FILL  COM  MSGBUF  (LOAD  MESSAGE).  DEACTIVATE  MSG  FRAME 
IS  BASED_AT  ADDRESS  ZERO.  IT  IS  OVERLAID  ONTO 
COM  MSGBUF  FRAME  BY  INDEXING  EACH  ENTRY  (I.E.  ADD¬ 
ING  mO  EACH  ENTRY)  THE  BASE  ADDRESS  OF  COM  MSGBUF! 


00  se 

4DD5 

LD 

DEACTIVATE, 

MSG.DEACT  CODE ( R12 ' , 

00E2 

0000 

#DS ACT1VATE_C0DF 

00E4 

0035 

00E6 

6FD1 

LD 

deactivate. 

MSG . D_DBR_NO ( R12 ) . R1 

00E8 

0002 

00EA 

3125 

LD 

Rb,P2(#0) 

! INDEX  TO  MM, KAN DLE  ENTRY  ! 

00EC 

0000 

00EE 

6FD6 

LD 

DEACTIVATE, 

MSG.D_MM_HANELE(0J (R13) ,R6 

00F0 

0004 

00F2 

3126 

LD 

R6,R2(*2) 

00F4 

0002 

00F6 

6FD6 

LD 

DEACTIVATE, 

MSG  .D, MM, HAN  DLE  (l  J  (P.13)  ,  R6 

00F8 

0006 

00F  A 

3126 

LD 

R6,R2(#4) 

00FC 

0004 

00FE 

6FD6 

LD 

DEACTIVATE, 

MSG . D_MM_HANDLE (2j (R13) , R6 

0100 

0008 

0102 

AIDS 

LD 

Re,  P.13 

0104 

5F00 

CALL 

PERFORM_IPC 

!  R8  :  "'COM, MSGBUF  ! 

0106 

018C' 
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RETRIEVE  SUCCESS_CODE  FROM  RETURNED  MESSAGE! 
£1^8  8E08  CIR  Re 

010A  60D8  LDB  RI0 ,PET_SUC_CODE .SUC_C0CE(P13 ' 

010c  0000 

010E  010F  ADD  R1S, #S I ZEOF  COM  MSG  ’RESTORE  STACK  STATE! 

0110  0010 

0112  9E08  R.ET 

0114  END  MM  DEACTIVATE 


0114  030F 
0116  0010 
0lie  AlFD 


MM  StfAP  IN  PROCEDURE 

|  y«*w*vV*»Vf*’*|!,**V*y«***|l|*****1*** 

’*  INTERFACE  BETWEEN  SEG  MGR  (SMJ* 
w  s'iAP  IN  PROCEDURE)  AND  MMGR  * 

*  (SWAP_IN  PROCEDURE ) .  ARRANGES  * 

^  AND  PERFORMS  IPC  .  * 

*  REGISTER  USE:  * 

*  PARAMETERS  * 

*  R0 :SUCCESS  CODE(RET)  9 

*  RisEBk  no (Input )  * 

*  :KPTR ( INPUT )  9 

*  R3 : A  CCES  S  (INPUT)  * 

*  LOCAL  USE  * 

*  R6 : MM  HANDLE  ARRAY  ENTRY  9 

*  R8:~CGM_MSGBUF  * 

*  R13  :~COM_MSGBUF  9 

wJStmwwjjtwwx'Swwwwwvwwwy'y'wy'wy' ! 

EN^R^ 

•USE  STACK  FOR  MESSAGE! 

SUB  R15 ,#S IZEOF  COM_MSG 

LD  R13.R15  !  ~COM_MSGBUF  ! 


011A 
011C 
011E 
0120 
0122 
0124 
0126 
0128 
012  A 
012C 
012E 
0130 
0132 
0134 
0136 
0138 
013A 
013C 
013E 
0140 
0142 
0144 


'FILL  COM  MSGEUF  (LOAD  MESSAGE).  SWAP_IN_MSG  FRAME 
IS  3ASSD~AT  ADDRESS  ZERO.  IT  IS  OVERLAID  ONTO 
COM  ^SGBUF  FRAME  BY  INDEXING  EACH  ENTRY  (I.E.  ADD- 
ING~T0  EACH  ENTRV)  THE  BASE  ADDRESS  OF  C0M_MSG3UF ! 


4DD5 
0000 
0036 
3126 
0000 
6FD6 
0002 
3126 
0002 
6FD6 
0004 
3126 
0004 
6FD6 
0006 
6Fn 
0008 
6FDB 
000A 
A1D8 
5F00 
0 18C  ' 


LD  S*fAP_lN_MSG .S_IN_C0DE(R13) ,#SW AP_IN_CODE 

LD  R6,R2(#0)  ! INDEX  TO  MM_HANDL£  ENTRY! 

LD  SWAP_IN_MSG.SI_MM_HANDLE10J (R13) ,R6 

LD  R6,?2(#2) 

ID  SWAP_IN_MSG.SI_MM_EANDL£(1J (R13^ ,R6 

ID  R6,R2(#4) 

LD  SWAP_IN_MSG.SI_MM_EANDL£[2]  (R13)  ,R6 

LD  SWAP_IN_MSG.SI_D£R_NO(R13) .HI 

LDB  SWAP_IN_MSG.SI_ACCESS_AUTH(R13URL3 

LD  R6.R13 

CALL  PER JQRM^IPC  !R8:  COM_MSGBUF! 


**■ 


! RETR IJfiVE  SUCCESS  CODE  FROM  RETURNEE  MESSAGE! 

45146  eoee  clr  Re 

0148  60D8  IDS  RL0.RET  SUC  CODE.SUC  C0EE(R13) 

014A  0000 

014C  010F  AED  R15,#S IZEOF  COM  MSG  JRESTORE  STACK  STATE 

014E  0010 

0150  9E08  RET 

0152  END  MM  SWAP  IN 


0152  MM  SWA?  OUT  PROCEDURE 

j  vww wwww v w»? w 

*  INTERFACE  BETWEEN  SEC  MGR  (SM  * 

*  SWAP  OUT  PROCEDURE )  AND  MMGR  * 

*  (SWAF  OUT  PROCEDURE).  ARRANGES* 

*  AND  PERFORMS  IPC.  * 

W  W  W  ¥  V  W  W  W  age  W *  W  V*  *  V  V  V  J**t Sf«  »)*  W  *e  age * 


V 

REGISTER  USE: 

3(5 

PARAMETERS 

*8 

3(8 

R0 iSUCCESS  CODE(RET) 

398 

3? 

Rl:DBR  NO(INPUT) 

3J8 

39« 

R2:HPTR( INPUT) 

398 

398 

LOCAL  USE 

V 

3»8 

R6:MM  HANDLE  ARRAY  ENTRY 

V 

>98 

R8 :  'COM  MSGBUF 

398 

3(8 

R13:~C0M  MSGBUF 

>98 

ENTRY 


!USE 

STACK  FOR  MESSAGE! 

0152 

030F 

SUB 

R15 , #S IZEOF  COM_MSG 

0154 

0010 

0156 

AlFD 

ID 

R13.R15  !  '*COM_MSG£UF  ! 

!EILL  COM  MSGBUF  (LOAD  MESSAGE).  SWAP  OUT_MSG  FRAME 
IS  SASED'aT  ADDRESS  ZERO.  IT  IS  OVERLAID  ONTO 
COM_MSGBUF  FRAME  BY  INDEXING  EACH  ENTRT  (I.E.  ADD¬ 
ING  TO  EACH  ENTRY)  THE  BASE  ADDRESS  OF  CCM_MSGBUF! 


0158 

4DD5 

LD 

SWAP_0UT_MSG.S_CUT_C0DE(R13)  ,  #SWAP_OUT_CODE 

015A 

0000 

015C 

0037 

R6,R2(#0)  ! I NDEX  TO  MM_HANDLE  ENTRY! 

015E 

3126 

ID 

0160 

0000 

SWAP_OUT_MSG.SO_MM_HANDL£l0j  (R13) ,R6 

0162 

6FD6 

LD 

0164 

0004 

0166 

3126 

LD 

R6,R2(#2) 

0168 

0002 

SWAP_OUT_MSG. S 0_*M_HAN DIE [ 1J  (R13>  ,R6 

016A 

6FD6 

LD 

016C 

0006 

R6,R2(#4) 

016E 

3126 

LD 

0170 

0004 

0172 

6FD6 

LD 

SWAP_OUT_MSG . SO_MM_HAN  DIE [2J (R13) ,R6 

0174 

0008 

0176 

6FD1 

LD 

SWAP_0UT_MSG.S0_D£R_N0(R13)  ,R1 

0178 

0e02 

017A 

A1D8 

LD 

R8.R13 

017C 

5F00 

CALL 

P£RFORM_IPC  !RB:  ~COM_MSG£UF ! 

017E 

018C  ' 
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0180  8D08 
0182  60D8 
0184  0000 
0188  010F 
0188  0010 
018A  9E08 
018C  END 


{RETRIEVE  SUCCESS  CODE  FROM  RETURNED  MESSAGE! 
CIR  R0 

LDfi  RL0 , RET_SUC_CODE ,SUC_CODE ( R12 ) 

Arc  Rl5 , £S I ZEOF  COM_^SG  'RESTORE  STACK  STATE 
RET 

MM  SWAP  OUT 
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018C  PERFORM  IPC  PROCEEURi 

J  wffjjtwwvww wwwwwwwwww 

*  SERVICE  ROUTINE  TO  ARRANGE  AND  * 

*  PERFORM  IPC  WITH  THE  MEM  MGR  PROC  * 

*  Jji  9  vv  w  V  ««  **  «« >5t  V  age  **  v*  W  *  W* 

*  REGISTER  USE:  * 

*  PARAMETERS  * 

*  R8  :  ''COM  MSG  ( INPUT  )  * 

*  LOCAL  USE  * 

*  R1.R2:  WORE  REGS  * 

*  R4 :  "G  AST  LOCK  * 

*  R13:  "COMjMSGEUF  * 

ENTRr 

018C  93FD  PUSH  PR15,R13  '."COM  MSGEUF! 

018E  5F0-0  CALL  GET  CPU_NO  JRET-R1  :CPU_N0 ! 

0190  0000* 

0192  A112  LD  R2,R1 

0194  6121  LE  R1,MM_CPU_TBL(K2)  !MM_VP_ID! 

0196  0000' 

0198  ?604  LDA  R4,G  AST  LOCK 

019 A  0000* 

019C  5F00  CALL  K_LOCK 

019E  0000* 

01A0  5F00  CALL  SIGNAL  !R1:MM_VP  ID,RE:"COM  MSGEUF 

01A2  0000* 

01A4  97FD  POP  R13, PR-15 

0 1A6  A1D8  LD  R8.R13  !"COM  MSGEUF! 

01A8  93FD  PUSH  0P.15.R13 

01AA  5F00  CALL  WAIT  !R8:"C0M  MSGEUF! 

01AC  0000* 

01AE  7604  LDA  R4 ,G_AST_LOCK 

0J.E0  0000* 

01E2  5F00  CALL  K_UNLOCK 

0134  0000* 

01B6  97FD  POP  P.13,  PF.15 

01Be  9E08  RET 

01BA  END  PERFORM  IPC 


01SA  MM  ALLOCATE  PROCEDURE 

I  W»**»*»W**M 

*  ALLOCATES  BLOCKS  OF  CPU* 

*  LOCAL  MEMORY  .  EACH  * 

*  BLOCK  CONTAINS  256  * 

*  BYTES  OF  MEMORY.  * 

wwwwwigiwwvw  www?* 

*  PARAMETERS:  * 

*  R3:  #  OF  BLOCKS  * 

*  RETURNS:  * 

*  R2 :  STARTING  ADDR  * 

*  LOCAL:  * 

*  R4 :  BLOCK  POINTER  * 

J WWWWVWWW J 


01J5A  B331 
01BC  0006 


01 BE  6104 
01C0  0F00' 
01C2  7642 
01C4  0000' 
01C6  ei34 


01C8  6F04 
OlC A  0F00 ' 
01CC  9E08 
01CE 


ENTRY 

f  NOTE:  THIS  PROCEDURE  IS  ONLY  A  STUB 
OF  THE  ORIGINALLY  DESIGNED  MEMORY 
ALLOCATING  MECHANISM.  IT  IS  T’SED 
By  *EE  PROCESS  MANAGEMENT  DEMONSTRATION 
TO  ALLOCATE  CPU  LOCAL  MEMORY  FOR  ALL 
MEMORY  ALLOCATION  REQUIREMENTS.  IN  AN 
ACTUAL  SASS  ENVIRONMENT ,  THIS  WOULD 
BE  BETTER  SERVED  TO  HAVE  SEPARATE 
ALLOCATION  PROCEDURES  FOR  KERNEL  AND 
SUPERVISOR  NEEDS.  (E.G.,  KERNEl_ ALIO CATE 
AND  SUPERVISOR  ALLOCATE),  t 

!  COMPUTE  SIZE  OF  MEMORY  REOUES TEE  ! 

SIX  R3,  #BLOCK_SIZE 

!  COMPUTE  OFFSET  OF  MEMORY  THAT  IS 
TO  BE  ALLOCATED  ! 

LD  R4,  NEXT_BLOCK  .'OFFSET! 

LDA  R2,  MEM_P00L(R4)  ! START  ACER! 

ADD  R4,  R3  JUPDATE  OFFSET! 

!  UPDATE  OFFSET  IN  SECTION  OF  AVAILABLE 
MEMORY  TO  INDICATE  THAT  CURRENTLY 
REQUESTED  MEMORY  IS  NOW  ALLOCATED  ! 

LD  NEXT  BLOCK,  R4  !SAVB  OFFSET! 


RET 

END  MM  ALLOCATE 


eiCE  MM  TICKET  PROCEDURE 

•  *****  ************9****  ******* 

’*  RETURNS  CURRENT  VALUE  OF  * 

*  SEGMENT  SEQUENCER  AND  * 

*  INCREMENTS  SEQUENCER  VALUE* 

*  FOR  NEXT  TICKET  OPERATION  * 

***************************** 

*  PARAMETERS:  * 

*  Rl:  SEG  HANDLE  PTR  * 

*  RETURNS:  * 

*  RR4 :  TICKET  VALUE  * 

*  LOCAL  VARIABLES:  * 

*  RR6 :  SEQUENCER  VALUE  * 

5)1  R8 :  G  AST  ENTRY  #  * 

*****************************  j 

ENTRY 

!  SAVE  HANDLE  PTR  ! 

01CE  93F1  PUSH  0R15,  Rl 
!  LOCK  G  AST  ! 

01D0  7604  LDA  R4,  G_AST_LOCK 

01D2  0000* 

01D4  5F00  CALL  K  LOCK 

01D6  0000* 

!  RESTORE  HANDLE  PTR  ! 

01D8  97F1  POP  Rl,  0R15 

!  GET  G_AST  ENTRY  #  ! 

01DA  6118  LD  R8 ,  MM  HANDLE. ENTRY  NO(Rl) 

01DC  0004 

!  GET  TICKET  VALUE  ! 

01DE  54ee  LDL  RRb,  G  AST . SEQUENCER (?.e ) 

01E0  0014* 

!  SET  RETURN  REGISTER  VALUE  ! 

01E2  9464  LDL  RR4 .  RR6 

! ADV ANCE  SEQUENCER  FOR  NEXT 
TICKET  OPERATION! 

01E4  1606  ADDL  RR6,  #1 

01E6  0000 
01E8  0001 

!  SAVE  NEW  SEQUENCER  VALUE  IN  G  AST  ! 
01EA  5D66  IDL  G  AST. SEQUENCER ( R8  )  ,  RR6 
01EC  0014* 

!  UNLOCK  G  AST  ! 

!  SAVE  RETURN  VALUES  ! 

01EE  91F4  PUSHL  <?R15,  RR4 

01F0  7604  LDA  R4,  G_AST_LOCK 

01F2  0000*  ~ 

01F4  5F00  CALL  K  UNLOCK 

01F6  0000* 

!  RETRIEVE  RETURN  VALUES  ! 

01F8  95F4  POPL  RR4,  PR15 

01FA  9E08  RET 

01FC  END  MM  TICKET 
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01FC  MM  READ  EVENTCOUNT  PROCEDURE 

i  ww^au**************************** 

*  READS  CURRENT  VALUE  OF  THE  * 

*  EVENTCOUNT  SPECIFIED  BY  THE  * 

*  USER.  * 

«WW*VW»VW«*9V¥WV«tl*W«**«« 

*  PARAMETERS:  * 

*  Rls  SEG  HANDLE  PTR  * 

*  R2 :  INSTANCE  (EVENT  #)  * 

*  RETURNS:  * 

*  RR4 :  EVENTCOUNT  VALUE  * 

vw  w*  vmm  *********** 

*  LOCAL  VARIABLES:  * 

*  RR6 :  SEQUENCER  VALUE  * 

*  R8 :  G_AST  ENTRY  #  * 

a**c*c  ******  ww**!:?***!  wane*  at*****)*!*  I 


ENTRT 


!  SAVE  INPUT  PARAMETERS  ! 

01FC 

93F1 

PUSH 

0R15,  R1 

01FE 

93F2 

PUSH 

9R15  f  R2 

!  LOCK  G  AST  ! 

0200 

7604 

LDA 

R4 ,  G_AST_LOCK 

0202 

0000‘S1 

0204 

5F00 

CALL 

K_LOCK 

0206 

0000* 

!  RESTORE  INPUT  PARAMETERS  ! 

0208 

97F2 

POP 

R2,  0R15 

020A 

97F1 

POP 

Rl,  OR15 

!  GET 

G  AST  ENTRT  #  ! 

020C 

6118 

LD 

R8,  MM  HANDLE. ENTRT  NO 

020E 

0004 

021k) 
0212 
0214 
0216 
0218 
021 A 
021C 
021E 
0220 
0222 
0224 
0226 
0228 
022A 
022C 


0B02 
0001 
5E0E 
0224' 
5484 
0018* 
2100 
0002 
5E08 
023C  ' 
0B02 
0002 
5E0E 
0238' 
5484 


!  READ  EVENTCOUNT  ! 

!  CHECK  WHICH  EVENT  #.  ! 
IF  R2 

CASE  #INSTANCE1  THEN 


LDL  RP.4,  G_AST.EVENT1(R8) 
LD  R0 ,  #SUCCEEDED 
CASE  #INSTANCE2  THEN 


LDL  RR4,  G_AST.EVENT2(R8) 
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022E 

001C* 

0230 

0232 

2100 

0002 

LD 

R0, 

^SUCCEEDED 

0234 

0236 

5E08 
023C  ' 

ELSE 

! INVALID  INPUT! 

0238 

023A 

2100 
005F  ■ 

LD 

R0, 

#1 NVALID_ INSTANCE 

FI 

!  NOTE:  NO  VALUE  IS  RETURNED  IF 


USER  SPECIFIED  INVALID  EVENT  »l 
!  SAVE  RETURN  VALUES  ! 

023C  91F4  PUSHL  GRIS,  RR4 
!  UNLOCK  G  AST  ! 

023E  7604  LDA  R4,  S_AST_LOCK 

0240  0000* 

0242  5F00  CALL  K  UNLOCK 

0244  0000* 

!  RESTORE  RETURN  VALUES  ! 

0246  95F4  POPL  RR4,  0R15 

0248  9E08  RET 

024A  END  MM  READ  EVENTCOUNT 
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024A  MM  ADVANCE  PROCEDURE 

*  DETERMINES  G  AST  OFFSET  FROM  * 

*  SEGMENT  HANDLE  AND  INCREMENTS  * 

*  THE  INSTANCE(EVSNT  #)  SPECIFIED  9 

*  BY  TEE  CALLER.  THIS  IN  EFFECT  * 

*  ANNOUNCES  THE  OCCURRENCE  OF  THE  * 

*  EVENT.  THE  NEW  VALUE  CF  THE  * 

*  EVENTCOUNT  IS  RETURNED  TO  THE  * 

*  CALLER.  * 

v  PARAMETERS :  * 

*  PI:  HANDLE  POINTER  * 

*  R2:  INSTANCE  (EVENT  «) 

yy*«**my**M*«y*«f  w***********;** 

*  RETURNS:  * 

*  RR2 :  NEW  EVENTCOUNT  VALUE  * 

99*>|up*****v*i|c*«*«*c**]|ivv:et*****v>|(*v>|t*  J 


ENTRY 

!  SAVE  INPUT  PARAMETERS  ! 


024A 

93F1 

PUSH 

0R15,  R 1 

024C 

93F2 

PUSH 

0R15,  R2 

!  LOCK 

:  G  AST  ! 

024E 

7604 

LDA 

R47  g_ast_lock 

0250 

0000V 

0252 

5F00 

CALL 

K_LOCK 

0254 

0000V 

!  RESTORE  INPUT  PARAMETERS 

0256 

97F2 

POP 

R2,  PR15 

0258 

97F1 

POP 

HI,  0R15 

!  GET 

G  AST  OFFSET  ! 

025A 

6114 

LD 

R4,  MM  HANDLE. ENTRY 

025C 

0e04 

!  DETERMINE  INSTANCE  ! 

IF  R2 

025E 

0B02 

CASE 

#INSTANCE1  THEN 

0260 

0001 

0262 

5E0E 

0264 

027C  * 

0266 

5442 

LDL 

RR2,  G_AST.  EVENT1  (■ 

026e 

0018V 

026A 

1602 

ADDL  RR2,  #1 

026C 

0000 

026E 

0001 

!  SAVE  NEW  EVENTCOUNT  ! 

0270 

5D42 

LDL 

G_AST .EVENTl ( R4  )  ,  , 

0272 

0018V 

0274 

2100 

LD 

R0  ,  WSUCCEEDED 

0276 

0002 

0278 

5E08 

CASE 

#INSTANCE2  THEN 
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027 A  029E' 
027C  0Be2 
027E  0002 
0280  5S0E 
0282  029 A  ' 
0284  5442 
0288  001C* 
0288  1602 
028A  0000 
028C  0001 

028E  5D42 
0290  001C* 
0292  2100 
0294  0002 
0296  5E08 
0298  02.91' 
029 A  2100 
029C  005F 


029E  7604 
02A0  0000* 
02A2  5F00 
02A4  0000* 
02A6  9E08 
02A8 


LDL  RR2,  G_AST . EVENT2 ( R4 ) 
ADDL  RR2.  #1 


!  SAVE  NEW  EVENTCOUNT  ! 

LDL  G_AST.EVSNT2(R4),  RR2 

LC  R0 ,  #SUCCEEDED 

ELSE  ! INVALID  INPUT! 

LD  R0,  #1 NV AL I D_ INSTANCE 

FI 

!  NOTE:  AN  INVALID  INSTANCE  VALUE 
WILL  NOT  AFFECT  EVENT  DATA  ! 

!  UNLOCK  G_AST  I 
LDA  R4,  G_AST_LOCK 

CALL  K_UNLOCK 

PET 

END  MM  ADVANCE 
END  DIST  MM 
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APPENDIX  D  -  GATS  KEEPER  LISTINGS 


Z8000ASM  2.02 

LOC  OBJ  CODS  STMT  SOURCE  STATEMENT 

KERN£L_GATE_KEEPER  MODULE 

$IIST0N  5TTT 

CONSTANT 

ADVANCE  CALL 
AWAIT  CALL 
CREATE  SEG  CALL 

delete's eg'call 

MAKE  KNOWN  CALL 
READ'CALL 
SM  SWAP  IN_CALL 

sm'swap'out  CALL 
TERMINATE  CXlL 
TICKET  CALL 
WRITE  CALL 

writeIn  call 

CRLF_CALL 
WRITE 
WRITSLN 
CRIF 
MONITOR 

REGISTER  BLOCX 
TRAP  CODE  OFFSET 
INVALID  KERNEL  ENTRY 


GLOBAL 

GATE_KEEPEF_FNTRI 

LABEL 

EXTERNAL 

ADVANCE 

PROCEDURE 

AWAIT 

PROCEDURE 

CREATE  SEG 

PROCEDURE 

DELETE'S  EG 

PROCEDURE 

MAKE  KNOWN 

PROCEDURE 

read- 

PROCEDURE 

S M  SWAP  IN 

PROCEDURE 

sm'swap'out 

PROCEDURE 

terminate 

PROCEDURE 

TICXET 

PROCEDURE 

KERNEL  EXIT 

LABEL 

INTERNAL 

SSECTION  KERNEL^GATE_ 

FROC 

1 

2 

3 

4 

R 

6 

7 

8 

9 

10 
11 
12 
13 

®0FC8 

Z0FCU 

S0FE4 

*A902 

32 

36 

TEAL 


SPRINT 

SPRINT 


CHAR! 

MSG! 


! CAP  RE? /II NX  FEED! 
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0000  GATE_KEEPEF_MAIN  procedure 

ENT?t 

GATE  KEEPER  ENTP.lt  : 

!  Save  registers  s 

0000  030F  SUB  R15,  #REGISTER  BLOCK 
0002  0020 

0004  1CF9  LDM  0R15,  Rl,  #16 

0006  010F 

!  SAVE  NSP  ! 

0008  93F2  PUSH  GR15,  R2 

000A  7D27  LDCTL  R2,  NSP 

!  RESTORE  INPUT  REGISTERS  ! 

000C  2DF2  EX  R2«  GRlb 

!  SATE  REGISTER  2  ! 

000E  93F2  PUSH  <?R15,  R2 

!  GET  SYSTEM  TRAP  CODE  ! 

0010  31F2  ID  R2,  R15(*TRAP  CODE  OFFSET) 

0012  0024 

!  REMOVE  SYSTEM  CALL  IDENTIFIER  FROM 
SYSTEM  TRAP  INSTRUCTION  ! 

0014  8C28  CLRB  RH2 

!  NOTE:  THIS  LEAVES  THE  USER  VISIBLE 
EXTENDED  INSTRUCTION  NUMBER  IN  R2  ! 

!  DECODE  AND  EXECUTE  EXTENDED  INSTRUCTION  ! 
IF  R2 

!  NOTE:  THE  INITIAL  VALUE  FOR  REGISTER  2 
WILL  BE  RESTORED  WHEN  THE  APPROPRIATE 
CONDITION  IS  FOUND  ! 

0016  0£02  CASE  #ADVANCE  CALL  THEN 

0018  0001 
001 A  5E0E 
001C  0028' 

001B  97F2  POP  P.2,  9R15 

0020  5F00  CALL  ADVANCE 

0022  0000* 

0024  5E08  CASE  #AWAIT  CALL  THEN 
0026  010C  ' 

0028  0B02 
002A  0002 
002C  5E0E 
002E  003A ' 

0030  97F2  POP  R2,  (? Rl 5 

0032  5F00  CALL  AWAIT 

e034  0000* 

0036  5E08  CASE  #CF.EATF  SSG  CALL  THEN 
0038  010C ' 

003A  0B02 
003C  0003 
003E  5E0E 
0040  004C  ' 
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0042 

97F2 

POP 

R2,  ORlb 

0044 

5E00 

CALL 

CPEATE_SEG 

0046 

0000* 

0048 

5E08 

CASS 

#DELSTF_S  EG_CALL 

THEN 

004A 

010C  ' 

004C 

0502 

004E 

0004 

0050 

5E0E 

0052 

005E  ' 

0054 

9^12 

POP 

R2,  (?R16 

0056 

5E00 

call 

DELSTi_SEG 

0058 

0000* 

ee5A 

5E08 

CASS 

#MAKS_KNOWN_CAIL 

then 

005C 

010C' 

005E 

0502 

e06e 

0005 

0062 

5E0E 

0064 

0070' 

0066 

97F2 

POP 

52,  8R15 

0068 

5F00 

cail 

MAKE_KNOWN 

006A 

0000* 

0e6C 

5E08 

CASS 

#?.EAD_CALL  THEN 

006E 

010C  ' 

0070 

0502 

0072 

0006 

0074 

5E0E 

0076 

0082' 

0078 

97F2 

POP 

R2,  ORlb 

007A 

5F00 

CALL 

read 

007C 

0000* 

007E 

5E08 

CASE 

#SM_SWAP_IN_CALL 

then 

0080 

010C  ' 

0082 

0E02 

0084 

0007 

0086 

5E0E 

0088 

0094' 

008A 

97F2 

POP 

P.2,  PR15 

008C 

5F00 

CALL 

SM_SWAP_IN 

006E 

0000* 

0090 

5S09 

CASE 

#SM_SWAP_OUT_CALL 

THE: 

0092 

010C  ' 

0094 

0E02 

0096 

0008 

0098 

5E0E 

009 A 

00A6  ' 

009C 

97F2 

POP 

52,  0R15 

009E 

5F00 

CALL 

SM_SWAP_OUT 

00A0 

0000* 

00A2 

5E08 

CASE 

#TERWINATE_CALL 

THEN 

00A4 

010C' 

00A6 

0502 
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nit Ae  00  e9 

5S0E 

00AC  00B8  * 
0eAE  97F2 
00B0  5F00 
00B2  0000* 
00B4  5E08 
00B6  010C' 
00 B8  0B02 
00  BA  000A 
003C  5E0E 
00BE  00CA  ' 
00 C0  9772 
00C2  5700 
00C4  0000** 
00C6  5Eee 
00C8  010C' 
00CA  0B02 
00CC  000B 
00CE  5S0E 
00D0  00DC  ' 
00D2  97F2 
00D4  5F00 
00D6  0FC8 
00De  5E08 
00 DA  010C' 
00DC  0B02 
00DE  0e0C 
00E0  5E0E 
00E2  00EE ' 
00E4  97F2 
00E6  5F00 
00E8  0FC0 
00EA  5E08 
00EC  010C' 
00 EE  0B02 
eeF0  eeeD 
00F2  5E0E 
00F4  0100' 
00F6  97F2 
00F8  5700 
00FA  0FD4 
00FC  5E08 
00FJS  010C' 


0100  7601 
0102  0100' 


POP  R2,  ORlb 
CALL  TERMINATE 

CASE  ^TICKET  CALL  THEN 


POP  R2,  ORlb 
CALL  TICKET 


CASE  # WRITE  CALL  THEN 


POP  R2,  ORlb 
CALL  WRITE 


CASE  #WRITSLN  CALL  THEN 


POP  R2,  ORlb 
CALL  WRITELN 

CASE  #CRLF  CALL  THEN 


POP  P2,  ORlb 
CALL  CRLF 

ELSE  ! INVALID  KERNEL  INVOCATION ! 

!  RETURN  TO  MONITOR  ! 

!  NOTE:  THIS  RETURN  TO  MONITOR  IS 
FOR  STUB  USE  ONLY.  AN  INVALID 
KERNEL  INVOCATION  WOULD  NORMALLY 
RETURN  TO  USER.  ! 

LDA  PI,  $ 


171 


0104  2100  LD  ?.0,  #INVALID  KERNEL_ENT3Y 

0106  0BAD 

0108  5F00  CAIL  MONITOR 

0 10A  A902 

FI 

!  SAVE  REGISTERS  ON  KERNEL  STACK  ! 
!  SAVE  HI  ! 

010C  93F1  PUSH  0R15,  Rl 

!  GET  ADDRESS  OF  REGISTER  BLOCK  ! 
010E  34F1  LDA  Rl,  R15(#4) 

0110  0004 

!  SAVE  REGISTERS  IN  REGISTER  BLOCK 
ON  KERNEL  STACK.  ! 

0112  1C  19  IDM  PR1 ,  El,  #16 

0114  010F 

!  RESTORE  Rl  BUT  MAINTAIN  ADDRESS 
OF  REGISTER  BLOCK  ! 

0116  2DF1  E'X  Rl,  OR15 

!  SAVE  Rl  ON  STACK  ! 

0110  33F1  LD  R15 ( #4 ) ,  Rl 

011A  0004 

!  RESTORE  REGISTER  BLOCK  ADDRESS  ! 
011C  97F1  POP  Rl,  (iRlb 

!  SAVE  VALID  EXIT  SP  VALUE  ! 

011E  33F1  LD  R15 ( #30 ) ,  Rl 

0120  001E 

!  EXIT  KERNEL  BY  MEANS  OF  HARDWARE 
PREEMPT  HANDLER  ! 

0122  5E08  JP  KERNEL  EXIT 

0124  0000* 

0126  END  GATS  KEEPER  MAIN 

END  KERNEl  GATE  KEEPER 
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Z8000ASM  2.02 

ioc  oe:  code 


STMT  SOURCE  STATEMENT 


USER_GATE  MODULE 

$LISTON  STTY 
CONSTANT 

ADVANCE_CALL  :=  1 

AWAIT  CALL  :=  2 

CREATE  SEC  CALL  :=  3 

DELETS“S£G-CALL  :=  4 

MAKE  KNOWN-CALL  :=  b 

READ~CALL  ”  :=  6 

SM  SWAP  IN  CALL  :=  7 

Sm2SWAP"OUT  CALL  :=  fc 

TERMINATE  CALL  :=  9 

TICKET  CALL  :=  10 

WRITE  CALL  :=  11 

VRITELN  CALL  :  =  12 

CRLF_CALL  :=  13 

GLOBAL 

^SECTION  USaR_GATE_PROC 
0000  ADVANCE  PROCEDURE 


(  I|i**y*i|[i|i*w*«*v**i|i*****9« 

’*  PARAMETERS:  * 

*  RlrSEGMENT  #  * 

*  R2  :  INSTAN  CE  ( ENTRY#) * 

*  RETURNS:  * 

*  R0 '.SUCCESS  CODE  * 

*««f*»**y*f**y»v***««)|i*v  f 


EN'T'RT 

eeee 

7F01 

SC  ^ADVANCE  CALL 

0002 

9E0B 

RET 

0004 

END  ADVANCE 

000A 

AWAIT  PROCEDURE 

1  yyyyw*«»yyyyy*«i|iywf** 

*  PARAMETERS: 

*  Rl:SEGMENT  # 

* 

*  R2: INSTANCE 

V 

*  RR4 :SPECIFIED  VALUE 

M 

Hi* 

*  RETURNS: 

V 

*  P0 : SUCCESS  CODE 

V 

V*W***«**V*iV***l?*«V*4<V’t‘  I 

ENTRY 
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0004  7F02 
000s  9S08 

0009 

0008 


000C  ?F04 
000E  9E08 
0010 

0010 


SC  » A WAIT  CALL 

END  AWAIT 

CREATE_SEG  PROCEDURE 


* 

PARAMETERS : 

* 

* 

Rl : MENTOR  SEG  NO 

* 

-V 

R2: ENTRT  NO 

R3:SIZ£ 

>JC 

V 

RR4  :CLASS 

* 

0008  7F03 
000 A  9E08 
000  C 

000C 


*  RETURNS :  * 

*  R0:SUCCESS  COLE  * 

ENTRY 

SC  #CREATE  SEC-  CALI 
RET 

ENC  CREATE  SEG 


0010  7F05 
0012  9E08 
0014 


DELETE_SEG  PROCEDURE 

*  PARAMETERS :  * 

*  R1:ME’NT0R_SEG_N0  * 

358  R2 :  ENTRY_N0  * 

*  RETURNS:  * 

*  R0: SUCCESS  CODE  * 

ENTRY 

SC  #DELETE  SEG  CALL 

RET 

END  DELETE_SEG 
MAKE_KNOWN  PRCCEDURS 

» vww  jjcvwww 

*  PARAMETERS:  * 

*  Rl: MENTOR  SEG  NO  * 

*  R2 : ENTRY  NO  * 

*  R3:ACCESS  DESIRED  * 

V  W  W  U  V  W  W  V  V  M «<»*  V  ¥  J?  «V 

*  RETURNS:  * 

*  R0 ‘.SUCCESS  CODE  * 

*  Rl: SEGMENT  #  * 

*  R2 : ACCESS  ALLOWED  9 

ENTRT 

SC  #MAKE  KNOWN  CALL 

RET 

END  MAKE  KNOWN 


0014 


0014 

0016 

001S 

0018 


0018 
001 A 
001C 

001 C 


001C 

001E 

0020 

0020 


0020 


READ  PROCEDURE 

I  WWV  WWW  VMS*  mm  wmm 


5? 

PARAMETERS: 

* 

V 

Rl  :S  EGMENT  # 

V 

w2: INSTANCE 

V 

^V*VV9i«lVVV9VVWVMWVVV 

RETURNS : 

* 

* 

R0: SUCCESS  CODE 

V 

RR4 : EVENTCOUNT 

* 

W*  ! 

ENTRY 

7E06  SC  ffREAD  CALL 

9E08  RET 

END  READ 

SM  S WAP_IN  PROCEDURE 

518  PARAMETERS:  * 

*  Rl:  SEGMENT  »  * 

MMMM  WW  WMM  WM  WM 

*  RETURNS:  * 

»  R0:SUCCESS  CODE  * 

ENTRY 

7F07  SC  #SM  SWAP  IN  CALL 

9E08  RET 

END  SM_SWA?_IN 

SM_SWAP_OUT  PROCEDURE 

f  MMWWW  WWWWWW  WMVMV 

*  PARAMETERS:  * 

*  Rl: SEGMENT  *  * 

m  ww  mm  wwmwmwwwm  mw  wm 

*  RETURNS:  * 

*  ?0: SUCCESS  CODE  * 

W  WVMMWWVM age MM  WM MMWMMMWW  ; 

Jfi  NTR y 

7F08  SC  #SM_SWAP  OUT  CALL 

9E08  RET 

END  SM_SWAP_OUT 

TERMINATE  PROCEDURE 

t  mwwmwmw  wwmww  wmmvvwww 

*  PARAMETERS:  * 

*  Rl :  SEGMENT  *f  v 

*  RETURNS:  * 

*  P0:SUCCESS  CODE  * 

M  VMM  MW  W  WWMWMVM  WW  WM  { 

ENTRY 

?f 09  sc  terminate  call 


0022  9E09 
0024 


PET 

Nr  TERMINATE 


0024  TICKET  PROCEDURE 

j  >*  WWW  J(tJ?  WW  &VWWW  W  ¥ 

*  PARAMETERS :  v 

*  Rl :S  EGMENT  *  * 

*  RETURNS:  * 

*  R0:SUCCESS  CODE  * 

*  RR4 : TICKET  7ALUE  * 

ENTRY 


0024 

7F0A 

SC  ^TICKET  CALL 

e026 

9  £09 

RET 

0029 

END  TICKET 

0028 

rfRITE  PROCEDURE 

ENTRY 

0029 

7F0B 

SC  *WRITE_CALL 

002A 

9E08 

RET 

Z02C 

ENT  WRITE 

002C 

WRITELN  PROCEDURE 

ENTRY 

0  02  C 

?F0C 

SC  #WR 1T£LN_CALL 

002E 

9E08 

RET 

0030 

END  WRITEIN 

0030 

CRLF  PROCEDURE 

ENTRY 

0030 

7F0D 

SC  *CRLF  CALL 

0032 

9E09 

R  ST 

0034 

END  CRLF 

APPENDIX  E  -  BOQTSTRAP_ LOADER  LISTINGS 


Z8000ASM  2.02 

LOC  OBJ  CODE  STMT  SOURCE  STATEMENT 

BOOTS TRAP_LOADER  MODULE 

SLISTON  $TTY 
CONSTANT 


,  ********  SYSTEM  PARAMETERS  ******** 


NR  CPU 
NR~VP 

NP.  AVAIL  VP 

maI  dbr  nr 

STACK  SEG 
STACK~SEG  SIZE 

stack~bloCk 


2 

NR  CPU*4 

nr~c?u*2 

10“ 

1 

*1 00 

STACK_SEG_SIZE/2*b 


j 


!  *  *  OFFSETS  IN  STACK.  SEG  *  *  ! 
STACK  BASE  :=  STACK  SEG  SlZJs-%10 

STATUS  REG  BLOCK:*  STACK  SEg“SIZE-%10 
INTERRUPT  FRAME  :=  STACK  BASS-4 


INTERRUPT_REG 
N_S  P 
F_C  Jrf 

i  ******  SYSTEM 
ON 
OFF 
READY 
NIL 

INVALID 
KERNEL  FCW 
AVAILABLE 
ALLOCATED 
SC_OFFSET 

TTPE 

MESSAGE  ARRAY 
ADDRESS  WORD 
MM  VP  ID  WORD 
VP~INDEX 
MSS  INDEX 


:=  INTERRUPT  FRAME-34 
:=  I NTERRUPT~R EG-2 
:*  STACK_SEG_SIZE-*E 

CONSTANTS  ******  ! 

:=  %FFFF 
:=  0 
:=  1 

:=  XPFFF 
:  =  SEEEE 
:=  X50<ce 
:=  0 
:=  %7J 
:*  12 


[lb  BYTEJ 


INTEGER 

integer 


17? 


MSG  TABLE  RECORD 
[  "!SG  MESSAGE 

SENDER  7 P  INDEX 

NEXT  MSG  MSG  INDEX 

FILLER  ARRAY  lb,  WORD] 

J 

TABLE  RECORD 
[  DBP.  ADDRESS 

PR  I  WORD 

STATE  WORD 

IDLE  FLAG  WORD 

PREEMPT  WORD 

PHTS_PROCESSOR  WORD 
NEXT  READY  7P  VP  INDEX 

MSG  LIST  “  MSG_ I NDEX 

EYT"ID  WORD 

FILLER  1  ARRAY  17,  WORDJ 

J 

EXTERNAL 

GET_DBR  ADDR  PROCEDURE 

CREATE_STACA  PROCEDURE 

LIST  INSERT  PROCEDURE 

ALLOCATE_MMU  PROCEDURE 

UPDATE  MMU.IMAGE  PROCEDURE 
MM_ALLOCATE  PROCEDURE 

MM~ENTRY  LABEL 

IDLE  ENTRY  LABEL 

PR£EMPT_RET  LABEL 

BOOTS TRAP _ ENTRY  LABEL 
GATE  KEEPER  ENTRY  LABEL 

nsxt~block  word 

MM  CPU  TPL  ARRAY [NR  CPU  MM_VP  IDJ 


VPT  RECORD 

[  LOCK  WORD 

RUNNING  LIST  ARRAY  [NR  CPU  WORDJ 
READY  LIST  ARRAY  [NR^CPU  WOF.EJ 
FREE  LIST  MSG  INDEX 

VIRT~INT  VEC  ARRAY  [1,  A DDRESS J 
FILLER  2  WORD 

VP  ~  ARRAY  [NR  VP,  VP  TABLEJ 

MSG  C  ARRAr  InR  VP,  MSG_TABL£j 


J 


EXT  VP  LIST  ARRAY  [NR  AVAIL  VP  WORD] 
NEXT_AVAIL_MMU  ARRAY  lMAX_DBR~NR  BITE] 

PRDS  RECORD 

IPHYS  CPU  ID  WORD 

log  cpu  Id  integer 

VP  NR  "  WORD 

IDlE  VP  VP  INDEX] 


internal 

SSECTION  LOADER_DATA 

!  NOTE:  ThESS  DECLARATIONS  WILL  NOT  WOPK 
IN  A  TRUE  MULTIPROCESSOR  ENVIRONMENT  AS 
THEY  ARE  SUBJECT  TO  A  "CALL."  THEY  MUST 
BE  DECLARED  AS  A  SHARED  GLOBAL  DATABASE 
WITH  "RACE”  PROTECTION  (E.G.,  LOCK).  ! 

0000  NEXT  AVA IL_VP  INTEGER 

0002  N£XT~EXT  VP  INTEGER 
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ee'00 


e000  4T05 

0002  0000s*5 

0004  FFFF 


SSECTICN  LOADER  I NT 
INTERNAL 

BOOTS TRAF  PROCEDURE 

*  CREATES  KERNEL  PROCESSES  AND  * 

*  INITIALIZES  KERNEL  DATABASES . * 

*  INCLUDES  INITIALIZATION  OF  * 

*  VIRTUAL  PROCESSOR  TABLE,  * 

*  EXTERNAL  VP  LIST,  AND  MMU  * 

*  IMAGES.  ALLOCATES  IMAGE  * 
355  AND  CREATES  KERNEL  DOMAIN  * 

*  STACK  FOR  KERNEL  PROCESSES.  * 


ENTRY 

!  INITIALIZE  PRDS  AND  M.MU  POINTER  ! 

!  NOTE:  THE  FOLLOWING  CONSTANTS  ARE 
ONLY  TO  BE  INITIALIZED  ONCE.  THIS 
WILL  OCCUR  DURING  SYSTEM  INITIALIZATION! 
LD  PRDS.PHYS  CPU  ID,  #'?FFFF 


!  NOTE:  LOGICAL  CPU  NUMBERS  ARE  ASSIGNED 
IN  INCREMENTS  OF  2  TO  FACILITATE  INDEXING 
(OFFSETS)  INTO  LISTS  SUBSCRIPTED  Bv 
LOGICAL  CPU  NUMBER.  ! 


•  . 

0006 

4D05 

LD 

PRDS.LOG_CFU_ID,  #2 

0008 

0002* 

000  A 

0002 

4  l 

•. 

! 

SPECIFY  NUMBER  OF  VIRTUAL  PitCCESS 

ASSOCIATED  WITH  PHYSICAL  CPU.  f 

.  V 

000C 

4D05 

LD 

PRDS . VP_NR ,  #2 

-Mt 

0e0E 

0004* 

0010 

0002 

* 

0012 

4D08 

CLP. 

NEXT.BLOCK 

i 

0014 

0000s* 

* 

0016 

4D08 

CLR 

N  EX  T_  A  V  A I  L_  V  P 

T 

0018 

0000  ' 

t 

001 A 

4D08 

CLR 

N  EXT_EXT_VP 

001C 

0002' 

001E  7D15 


0020  0101 
0022  000C 

0024  0D15 
0026  5000 


!  ESTABLISH  GATS  KEEPER  AS  SYSTEM  CALL 
TRAP  HANDLER  ! 

!  GET  BASE  OF  PROGRAM  STATUS  AREA  ! 

LOCTL  Rl,  PSAP 

!  ADD  SYSTEM  CALL  OFFSET  TO  PSA  BASE  AD DR  ! 
ADD  Rl,  #SC_QFFSET 

!  STORE  KERNEL  FCW  IN  PSA  ! 

LD  0»Plf  #KSRNfiL_FC W 


!  STORE  ADDRESS  0?  SATE  KEEPER  IN  PROGRAM 


STATUS 

AREA 

AS  SYSTEM  TRAP  HANDIER 

; 

0028 

A911 

INC 

Rl, 

m 

002  A 

0D15 

LD 

0R1 

,  #GATE_K5EPER_EN 

TRY 

002C 

0000* 

002E 

8D18 

CL? 

?.l 

l  NE  T_AVAIL_MMU 

INDEX 

; 

!  INITIALIZE 

ALL  MMrJ  IMAGES  AS 

AVAIIABLE 

SET_MMU_MAP 

• 

• 

DO 

0030 

4C15 

IDE 

NEXT  AVAIL  MMU(Rl), 

#AVAILAJ:LE 

0032 

0000* 

0034 

0000 

0036 

A910 

INC 

Rl, 

#1 

!  CHECK  FOR 

END  OF  TABLE  ? 

0038 

0B01 

CP 

Rl, 

*MAX_DBR_NR 

003A 

000A 

003C 

5E0E 

IF  EO 

THEN 

exit  From  set_mmu 

_MAP 

FI 

003E 

0044' 

0040 

5E08 

0042 

0046' 

0044 

E8F5 

OD 

!  CREATE  MEMORY  MANAGER  PROCESS  ! 

45046  2103  LD  S3,  #STA Cl  .BLOCK 

0048  0001 

I  ALLOCATE  AND  INITIALIZE  KERNEL 
DOMAIN  STACK  SEGMENT  1 

004A  5E00  CALL  MM  ALLOCATE  ! R3 :  #  OP  SLCCKS 

004C  0000* 

RETURNS 

R2  :  START  ACT'S  ? 

004E  A121  LD  Rl,  R2 

0050  2103  LD  S3,  #KERNEL_FCW 

0052  5000 

0054  7604  LDA  R4,  MM_ENTRY 

0056  0000* 

005e  6105  LD  R5,  *FFFF  INSP! 

005A  TFFF 

005 C  7606  LDA  R6,  PREEMPT_RET 

005E  0000* 

0060  93F1  PUSH  PR15,  Rl  !SAVE  STACK  ADIR ! 

0062  030F  SUB  R15 ,  »8 

0064  0008 

0066  1CF9  LDM  3R15,  R3 ,  #4 

0068  0303 

006A  A1F2  LD  R0 ,  R15 

\  NOTE:  ARGLIST  FOR  CREATE  STACK  INCLUDES 
5ERNEL_PCW ,  INITIAL  IC ,  NSP,  AND  INITIAL 
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RETURN  POINT.  ! 

006C  5F00  CALI  CREATE  STACK  !  (R0:  ARGUMENT  PTR 

006E  eeetf* 

Rl:  TCP  OF  STACK 
R2-R14:  INITIAL 
REG. STATES  ! 

0070  010F  ADD  Rib,  #8  !  OVERLAY  ARGUMENTS! 

0072  0008 

!  ALLOCATE  MMU  IMAGE  ! 

0074  5F00  CALL  ALLOCATE  MMU  ! RETURNS: 

0076  0000* 

( R0 :  LBR  # )  * 

0079  2iei  LD  Rl,  fcSTACK  SEG  !  SEGMENT  NO.  ! 

007 A  0001 

007C  97F2  POP  R2 ,  0R15  ! GET  STACK  ADLR ! 

007E  2103  LD  P.3 ,  #0  !  WRITE  ATTRIBUTE  ! 

0080  0000 

!  SPECIFY  NUMBER  OF  BLOCKS.  COUNT  STARTS 
FROM  ZERO.  (I.E. ,1  BLOCK=0,  2=1,  ETC.)! 

0082  2104  LD  R4,  #STACK  BLOCK-1 

0084  0000 

!  SAVE  DBR  #  ! 

0086  93F0  PUSH  0R15,  R0 

!  CREATE  MMU  ENTRY  FOR  MM  STACK  SEGMENT  ! 

0088  5F00  CALL  UPDATE  MMU_ IMAGE  !(R0:  DBR  * 

008A  0000* 

Rl:  SEGMENT  * 

R2 :  SEG  ADDRESS 
R3 :  SEG  ATTRIBUTES 
P.4:  SEG  LIMITS)  ! 

!  RESTORE  DBR  ft  ! 

008C  97F0  POP  R0,  PR1S 

!  GET  ADDRESS  OF  MMU  IMAGE  ! 

008S  5F00  CALL  GET  DBR  ADDR  !  (R0:  DER  #) 

0090  0000* 

RETURNS: 

*  fRl:  DBR  ADDRESS)  ! 

!  PREPARE  VP  TABLE  ENTRIES  FOR  MM  ! 


0092 

0094 

2ie2 

0002 

LD 

R2  , 

ft  2 

!  PRIORITY  ! 

0096 

0098 

2105 

0000 

LD 

R5 , 

#OFF 

!  PREEMPT  ! 

009A 

009C 

2106 

0000 

LD 

R6 , 

#OFF 

!  KERNEL  PROCESS  ! 

!  UPDATE  VPT  ! 

009E  5F00  CALL  UPDATE  7?  TABLE  !(R1:  DBR 

00A0  01CA ' 


R2 :  PRIORITf 


Rb:  PREEMPT  FLAG 
R6:  EXT  7P  FLAG) 

returns': 

R9:  VP  ID  ! 


!  INITIALIZE  MM  CPU  TBL  IN  DISTRIBUTED  MEMORY 

MANAGER 

WITH  VP  ID  OF  MM  PROCESS  ! 

!  GET  LOGICAL  CPU  #  ! 

00A2 

610A 

LD  R10,  PRDS  .LOG  CPU  ID 

00A4 

0002* 

00A6 

6FA9 

LD 

MM_CPU_T£L(R10) ,  R9 

00A6 

0000V 

!  CREATE 

IDLE  PROCESS  ! 

00AA 

2103 

LD 

R3,  #STACK_BIOCK 

00AC 

0001 

00AE 

5Fe0 

CALL 

MM_ALLOCATE  !R2 :  #  OF  BLOCKS 

00S0 

0000* 

RETURNS 

R2:  START  A DDR ! 

00JJ2 

A121 

LD 

Rl*  R2 

00B4 

2103 

LD 

R3 ,  #KERNEL_FCW 

00B6 

5000 

00B8 

7604 

LDA 

R4,  IDLE_£NTRI 

00BA 

0000V 

00BC 

2105 

LD 

P.5,  #SFFFF  !  NS P ! 

00BE 

FFFF 

00C0 

7606 

LDA 

P.6,  preempt.ret 

00C2 

0000* 

00C4 

93F1 

PUSH 

GRIS,  Rl  !SAVE  STACK  ADDR ! 

00C6 

030F 

SUB 

R15,  #9 

00C8 

0008 

00CA 

1CF9 

LDM 

0R15,  R3,  #4 

00CC 

0303 

00CE 

A1F0 

LD 

R0,  R15 

!  INITIALIZE  IDLE  STACK  VALUES  ! 

00D0 

5F00 

CALL 

CR£ATE_STACK  !  (R0:  ARGUMENT  PT* 

00D2 

0000* 

Rl  :  TOP  01  STACK 

R2-R14 :  INITIAL 

REG.  STATES  ' 

00D4 

010F 

ADD 

R15,  *8  ! OVERLAY  ARGUMENTS! 

0006 

0008 

!  ALLOCATE  MMU  IMAGE  FOR  IDLE  PROCESS  ! 

0008 

5F00 

CALL 

ALLOCATE_MMU  !  RETURNS  R0:DBP.  #  ! 

00DA 

0000* 

!  PREPARE 

IDLE  PROCESS  *MU  ENTRIES  ! 

00DC 

2101 

LD 

Rl,  #STACK_SEG  !  SEG  #  ! 

00OE 

0001 

00E0 

97F2 

POP 

R2,  OR lb  ! GET  STACK  ADDR! 

00E2  21453  LD  R3 ,  #45  !  4IRITE  ATTRIBUTE  ! 

00E4  0000 

00E6  2104  LD  R4 ,  #STACK  BLOCK-1  !  BLOCK  LIMITS  ! 

00E8  0000 

!  SAVE  DBR  n  ! 

00EA  93F0  PUSH  9R15,  R0 

!  CREATE  MMU  IMAGE  ENTR*  ! 

00EC  5F00  CALL  UPDATE  MMU  IMAGE  !(R1:  SEGMENT  * 

00EE  000e* 

R2 :  SEG  ADDRESS 
P3:  SEG  ATTRIBUTES 
R4:  SEG  LIMITS  )  ! 

!  RESTORE  DBR  ft  ! 

00F0  97F0  POP  R0,  »315 

!  GET  MMU  ADDRESS  ! 

00F2  5F00  CALL  GET  DBR  ADDR  !  (P.0:  L BP  ft) 

00F4  0000* 

RETURNS 

(Ri:  DBR  ADDRESS)  ! 

!  PREPARE  7PT  ENTRIES  FOR  IDLE  PROCESS  ! 

00F6  2102  LD  R2 ,  #0  !  PRIORITY  ! 

00F8  0000 

00FA  2105  LD  R5 ,  #OFF  !  PREEMPT  ! 

00FC  0000 

00FE  2106  LD  P.6 ,  #OFF  !  KERNEL  PP.OC  ! 

0100  0000 

!  CREATE  VPT  ENTRIES  ! 

0102  5F00  CALL  UPDATE  VP_TABLE  !(R1:  DBR 

0104  01CA' 

R2 :  PRIORITY 
R4 :  IDLE  FLAG 
R5 :  PREEMPT 
R6 :  EXT  VP  FLAG' 
RETURNS 7 
P.9:  VP  ID  ! 

!  ENTER  VP  ID  OF  IDLE  PROCESS  IN  PRDS  ! 


0106 

6F09 

LD 

PRDS  .IDLE_VP 

,  R9 

0108 

0006* 

; 

INITIALIZE  IDLE  VP'S 

! 

010A 

2102 

LD 

R2,  #1 

!  PRIORITY  ! 

010C 

0001 

010E 

2ies 

LD 

R5  •  #ON 

!  PREEMPT  ! 

0110 

FFFF 

0112 

2106 

LD 

R6,  #ON 

! NON-KERN  EL  PROC ! 

0114 

FFFF 

0116 

6100 

LD 

R0  ,  PRDS  .VP__ 

NR 

0118 

0004* 

!  INITIALIZE  VP  VALUES  ! 


DO 

011 A 

5F00 

CALL 

U?DATE_VP_TA3LE  !(Rl:  EBR 

011C 

01CA  ' 

R2 :  PRIORITY 

R4:  IDLE  FLAG 

R5:  PREEMPT 

R6 :  EXT  VP  FLAG) 
RETURNS? 

R9:  VP  ID  ! 

01115 

AB00 

DEC 

R0,  #1 

0120 

0B00 

CP 

R0  ,  #0 

0122 

0000 

0124 

5E0S 

IF  EC 

! ALL  VP'S  INITIALIZED!  THEN 

0126 

012C  * 

0128 

5E08 

SXI 

m 

X 

012A 

012E ' 

FI 

012C 

E8F6 

OD 

!  INlTILfZE  VPT  HEADER  ! 

!  GET  LOGICAL  CPU  NUMBER  ! 

012E 

6102 

LD 

R2,  PROS .LOG_CPU_ID 

0130 

0002* 

0132 

4D05 

LD 

VPT. LOCK ,  *0 FF 

0134 

0000* 

0136 

0000 

0138 

4D25 

LD 

VPT.RUNNING_LIST(R2),  #NIL 

013A 

0002* 

013C 

FITF 

013E 

4D25 

LD 

VPT.READI_LIST(R2) •  #NIL 

0140 

0006* 

0142 

FFFF 

0144 

4Dee 

CLR 

VPT ,FREE_LIST  'HEAD  CF  MSG  LIST! 

0146 

000A* 

'.THREAD  VP 

'S  BY  PRIORITY  AND  SET  STATES  TO  READY 

0148 

8D28 

CLR 

R2  JSTART  WITH  VP  #1! 

THREAD: 

DO 


014A 

014C 

610D 

0002* 

LD 

R13,  PRDS . LOG_CPU_ ID 

014E 

0150 

7bD3 

0006* 

LDA 

R3,VPT.READT_LIST(R13) 

0152 

0154 

7604 

001C* 

LDA 

R4, VPT.VP. NEXT_READY_VP 

0156 

0158 

7605 

0012* 

LDA 

R5, VPT. VP. PRI 

015A 

015C 

7606 

0014* 

LDA 

R6, VPT. VP. STATE 

015E 

2107 

LD 

R7,#READY 

0160 

0001 

!  SAVE 

OBJ  ID  ! 

0162 

93F2 

PUSH 

0R15,  R2 

0164 

5F00 

CALL 

LIST  INSERT  !R2:  OBJ  ID 

0166 

0000* 

R3:  LIST  HEAD  PTR  ADDS 
R4:  NEXT"OBJ  PTR 
P.5:  PR  I  OR  ITT  PTR 
R6:  STATE  PTR 
P.7:  STATE"  ! 


!  RES 

TORE  OBJ  ID  ! 

0166 

97F2 

POP 

R2 ,  OR 15 

ei6A 

0102 

ADD 

R2,  #S IZEOF  VP_TABLE 

016C 

0020 

016E 

0B02 

CP 

?2,  # ( NR_VP  *  (SIZEOF  VP_ TABLE )  ) 

0170 

0100 

0172 

5E0E 

IF  10 

THEN  EXIT  FROM  THREAD  FI 

0174 

017A ' 

0176 

5E08 

0179 

017C' 

017A 

E8E7 

OD 

!  INITIALIZE  VP  MESSAGE  LIST  ! 

!  NOTE:  ONL*  THE  THREAD  FOR  THE  MESSAGE 
LIST  NEED  BE  CREATED  AS  ALL  MESSAGES 
ARE  INITIALLY  AVAILABLE  FOR  USE.  THE 
INITIAL  MESSAGE  VALUES  WERE  CREATED 
FOR  CLARITY  ONLY  TO  SHOW  THAT  THE 
MESSAGES  HAVE  NO  USABLE  INITIAL  VALUE! 

017C  9D19  CLP  R1 

MSG  LST  IN  IT: 

"f  NOTE:  R1  REPRESENTS  CURRENT  ENTRY  IN 

MSG_LISTf  R2  REPRESENTS  CURRENT  POSITION 
IN  MSG  LIST  ENTRY,  AND  R3  REPRESENTS 
NEXT  ENTRT  IN  *SG  I*IST .  ! 

DO 


017E 

A112 

LD 

R2,  R1 

0180 

A123 

LD 

R3 ,  R2 

0162 

0103 

ADD 

R3 •  #S I ZEOF  MESSAGE 

0184 

0010 

FILL 

MSG: 

DO" 

0186 

4D25 

LD 

VPT ,MSG_C . MSG ( R2 ) ,  #INVALID 

0188 

0110* 

018A 

SEES 

018C 

A921 

INC 

R2,  #2 

018E 

8B32 

CP 

R2,  R3 

0190 

5E0E 

IF 

EO  THEN  EXIT  FROM  FILL  MSG  FI 

0192 

019e ' 

0194 

5E0S 

18b 


Efc-Z I 


0196 

019A' 

0iye 

ESF6 

OD 

0 19A 

4Dlb 

LD 

VPT.MSG_O.SENDER(Rl) .  #NIL 

0iyc 

0120’*' 

019E 

FFFF 

01A0 

A112 

LD 

R2,  R1 

01A2 

0101 

ADD 

Rl,  ffSIZEOF  MSG_TABLE 

01A4 

0020 

eiA6 

0E01 

CP 

Rl,  #S IZEOF  MSG_TA£LE*NR_V? 

01A9 

0100 

IF  EC 

01AA 

5E0E 

THEN 

01AC 

01BC' 

01AS 

4D25 

LD 

VPT .MSG_0 . NEXT_WSG (R2 ) ,  #NII 

01B0 

0122* 

01B2 

FFFF 

01B4 

5E08 

EXIT 

FROM  MSG_LST_INiT 

01B6 

01C2  0 

01B8 

5E0e 

ELSE 

01BA 

01C0' 

01BC 

6F21 

LD 

7PT.MSG_0.N£XT_MSG(R2) ,  Rl 

01BE 

0122* 

FI 

01C0 

ESDE 

OD 

!  GST  LGGICAI  CPU  #  FOR  USE 
B 7  ITC  GET WORK .  ! 

01C2  S10D  LD  R13,  PRDS.LOG  CPU  ID 

01C4  ee02* 

!  BOOTSTRAP  COMPLETE  ! 

!  START  SYSTEM  EXECUTION  AT  PREEMPT  ENTRV 
!  POINT  IN  ITC  GETWORX  PROCEDURE  ! 

01C6  5E08  JP  BOOTSTRAP  ENTRY 

01C8  0000* 

01CA  END  BOOTSTRAP 


01CA  UPDATE  VP  TABLE  PROCEDURE 


w 

INITIALIZES  VPT  ENTRIES 

V  w  W  W  W  WW  V  W  VVV  W  WWV  W  V 

* 

REGISTER  USE: 

PARAMETERS : 

* 

V 

Rl:  DBR  ADDRESS 

R2 :  PRIORITY 

* 

* 

R5:  PREEMPT  FLAG 

* 

V 

Rti :  EXTERNAL  7P  FLAG 

V 

V 

RETURNS: 

* 

jgs 

R9:  ASSIGNED  VP  ID 

* 

V 

LOCAL  VARIABLES : 

V 

* 

P.7:  LOGICAL  CPU  # 

* 

R8 :  EXT  VP  LIST  OFFSET 

* 

R9 :  VPT_OFFSET 

* 

ENTRY 

1 

GET  OFFSET  IN  VPT  FOR  NEXT  ENTRY  ! 

eiCA 

6109 

LD 

R9,  NEXT_AVAIL_VP 

01CC 

0000' 

01CE 

6F91 

LD 

VPT .VP .DBR (R9 }  ,  Rl 

01D0 

0010» 

01D2 

6F92 

LD 

VPT.VP.PRI  (P.9) ,  R2 

01D4 

0012^ 

01D6 

6F96 

LD 

VPT . VP . IDLE_FLAG ( R9 ) 

,  R6 

01D8 

0016V 

01DA 

6F95 

LD 

VPT .VP .PREEMPT (R9 ) , 

R5 

01DC 

0018V 

01DE 

6107 

LD 

R7,  PRDS .L0G_CPU_ID 

01S0 

0002V 

0 1E2 

6F97 

LD 

VPT.VP.PKYS_PRCCESSO 

R  (  R9  ^  ,  R7 

01E4 

001AV 

01E6 

4D95 

LD 

VPT. VP. NEXT  READY  VP(R9),  Sf NIL 

01E8 

001CV 

01EA 

FFFF 

01EC 

4D95 

LD 

VPT.VP.MSG_LIST(R9), 

#NII 

01EE 

001Ev 

01F0 

FFFF 

;  i 

CHECK  EXTERNAL  VP  FLAG  ! 

01F2 

0B06 

CP 

R6 ,  #ON 

01F4 

FFFF 

IF  EO  ! EXTERNAL  VP! 

01F6 

6E0E 

THEN  !  VP  IS  TC  VISIBLE  ! 

01F8 

0210' 

01FA 

6108 

LD  R8 .  NEXT  EXT  VP 

01FC 

0002' 

!  INSERT  ENTRY  IN  EXTERNAL  VP  LIST  ! 
LD  EXT_VP  LIST  (R8 ) ,  R9 
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01EE  6F89 


0200  0000* 

0202  6F98 

LD 

VPT. VP.EXT_ID(R9) ,  Re 

0204  0020* 

0205  A981 

INC 

R8,  #2 

0208  6Fe8 

LD 

NEXT_EXT_VP ,  R8 

020A  0002 ' 

020 C  5E08 

ELSE  !  VP  BOUND  TO  XEPNJSL  PROCESS! 

e20£  0216' 

0210  4D05 

LD 

VPT  .  VP .EXT_ID,  #NIL 

0212  0020* 

e214  FFFF 

FI 

0216  A19A 

LD 

Rl0 ,  P9 

0218  010A 

ADD 

P.10,  *S I ZSOF  VP_TAELE 

021A  0020 

021C  6F0A 

LD 

NEXT_AVA1L_VP,  P.10 

021 E  0000' 

0220  9E08 

RET 

0222 

END  UPDATE 

VP  TABLE 

END 

bootstrap" 

LOADER 
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APPENDIX  F  -  LLERARY  FUNCTION  LISTINGS 


Z8000ASM  2.02 

LOC  OBZ  CODE  STMT  SOURCE  STATEMENT 


LIERARv_FUNCTION  MODULE 
StlSTON  $TTI 


CONSTANT 

KERNEL  FCW  := 
STACK  SEG  SIZE  :  = 
STACK'BASE  :  = 
STATUS  REG  ELOCK:= 
INTERRUPT  FRAME  := 
InTERRUPT~REG  := 
N  S  P  ~  :  = 
NIL  :  = 


%5000 

STACK  SEG  SIZH10 
STACK  SEG  SIZE-^10 
STACK_BAS  E-4 
INTERRUPT  FRAME-24 
INTERRUPT" REG-2 
'fcFFFF 


niiiiie 


$ SECTION  LIS  ?POC 
GLOBAL 

LIST_iNSERT  PROCEDURE 

t  WWVJPWWWWWWWWWWWW&W 

*  INSERTS  OBJECTS  INTO  A  LIST  * 

*  BY  ORDER  OF  PRIORITY  AND  SETS  * 

*  ITS  STATS  * 

V*  W***#  WWW  Wtf  w  wv  *********** 

*  REGISTER  USE:  * 


V 

PARAMETERS : 

¥ 

V 

R2: 

OEJECT  ID 

¥ 

V 

R3: 

READ  OF  LIST 

PTR  ADDR 

* 

¥ 

R4 : 

NEXT  OBJ  PTR 

ADDR 

¥ 

V 

R5: 

PRIORITlf'PTR 

ADDR 

¥ 

V 

R6 : 

STATE  PTR  ADDR 

¥ 

V 

R7: 

OBJECT  STATE 

¥ 

¥ 

LOCAL  VARIABLES: 

¥ 

39c 

RS: 

READ  OF  LIST 

.PTR 

¥ 

V 

R9: 

NEXT  OBJ  PTR 

¥ 

V 

R10 

:  CURRENT~OBJ 

PRIORITY 

¥ 

39C 

Rll 

:  NEXT  OBJ  PRIORITY 

¥ 

BjgtVjgcwVWJt'VWW?? WV  sgt* t 


ENTRY 


!  GET  FIRST 

OBJECT  IN  LIST  ! 

0000 

2138 

LD 

R8 ,  PR3 

0002 

0E0e 

CP 

R8 ,  *NIL 

0004 

FFFF 

0006 

5E0E 

IF  EO  '.LIST 

IS  EMPTY!  TEEN 

0008 

0018' 

!  PLACE  OBJ 

AT  HEAD  OF  LIST  ! 

000A 

2F32 

LD 

OR  3,  R2 

000C 

7449 

LDA 

R9 ,  R4(R2) 

000E 

0200 

0010 

0D95 

LD 

PR9 ,  «NII 

0012 

FFFF 

0014 

5E08 

ELSE 

0016 

005A  ' 

!  COMPARE  OBJ  PRI  WITH  LIST  HEAD  PRI 

0018 

715A 

LD 

HI 0 ,  Rb(R2)  ! OBJ 

PRI ! 

001 A 

0200 

001C 

715B 

LD 

Rll,  R5(c8)  ! HEAD 

PRI! 

001E 

0800 

0020 

8BBA 

CP 

R10,  Rll 

0022 

5E02 

IF  GT  ! OBJ 

PRI>HEAD  PRI!  TEEN 

0024 

0030' 

0026 

2F32 

LD 

OR 3,  R2  ! PUT  AT 

FRONT 

0028 

734e 

LD 

R4 ( R2  )  ,  R8 

e02A 

02e0 

002c 

5S08 

ELSE  !  INSERT  IN  BODY  OF  LIST  ! 

»  r  V-'  ' 


t  r-  't *8**?  *•■- 3#*n 
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AD-A102  308 
UNCLASSIFIED 

l'3  I 


NAVAL  POSTGRADUATE  SCHOOL  MONTEREY  CA  F/6  9/2 

IMPLEMENTATION  OF  PROCESS  MANAGEMENT  FOR  A  SECURE  ARCHIVAL  STOP— ETC(U) 
MAR  81  A  R  STRICKLER 

NL 


8! 


00  2E  00 5A 


SEARCH  LIST: 
D0“ 


0030 

0B08 

CP 

R8 ,  #NIL 

0032 

FFFF 

0034 

5E0E 

IF  EC 

! END  OF  LIST!  THEN 

0036 

003C  ' 

0038 

5E08 

EXIT 

FROM  SEARCH_LIST 

003A 

0052' 

FI 

003C 

715B 

LD 

Rll ,  R5(R8)  ! GET 

NEXT  FRI 

003E 

0e00 

0040 

8BBA 

CP 

R10,  Rll 

0042 

5E02 

IF  GT 

!  CURRENT  PRI'*  NEXT  PR I ! 

TEEN 

0044 

004A  ' 

0046 

5E08 

EXIT 

FROM  SEARCH_LIST 

0048 

0052' 

FI 

!  GET 

NEXT  OBJ  ! 

004 A 

A189 

LD 

R9  •  R8 

004C 

7148 

LD 

R8 ,  R4(R9) 

004E 

0900 

0060 

E8EF 

<=> 

o 

END  SEASCH_LIST  ! 

!  INSERT  IN  LIST  ! 

0052 

7348 

LD 

R4(R2),  R6 

0054 

0200 

0056 

7342 

LD 

R4(R9),  R2 

0058 

0900 

FI 

FI 

!  SET  OBJECT'S  STATE  ! 

005A 

7367 

LD 

R6 ( R2  )  ,  R7 

005C 

02e0 

005E 

9E08 

RET 

0060 

END  LIST 

INSERT 
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0060 


CREATE_STACK  PROCEDURE 

J  WV  wa* VV0  WVM  W  JUV WW J* 

*  INITIALIZES  KERNEL  STACK  * 

*  SEGMENT  FOP.  PROCESSES  * 

wwviowwvw  vwvw 

*  REGISTER  USE:  * 

*  PARAMETERS:  * 

*  R0 :  ARGUMENT  POINTER  * 

*  ( INCLUDES :FCW,IC.NSP,  AND  * 

*  RETURN  POINT.  SEE  LOCAL  1(1 

*  VARIABLES  BELOW.)  * 

9  Ri:  TOP  OF  STACK  * 

*  R2-R14:  INITIAL  REGISTER  * 

*  STATES.  (NOTE:  IN  DEMO,  NO* 

*  SPECIFIC  INITIAL  REGISTER  * 

*  VALUES  ARE  SET,  EXCEPT  R13* 

*  (USER  ID)  FOR  USER  PRO-  * 

*  CESSES.)  * 

*  LOCAL  VARIABLES  * 

*  (FROM  ARGUMENTS  STORED  ON  * 

*  STACK.)  * 

*  R3 :  FCVf  * 

*  R4 :  PROCESS  ENTRY  POINT  (IO* 

*  R5:  NS?  * 

*  Rb:  PREEMPT  RETURN  POINT  * 


ENTET 

0060 

93F0 

PUSH 

0316,  R0  ! SAVE  ARGUMENT  PTP ! 

0062 

ADF0 

EX 

R0  ,  R15  !SAVE  SP ! 

0064 

341F 

LDA 

Rib,  Rl(#INTSRRUPT_REG) 

0066 

00CA 

0069 

1CF9 

LDM 

0316,  81,  *16  !  INITIAL  REG.  VAil’ 

006A 

010F 

!  NOTE: 

ONLT  REGISTERS  R2-F14  MAT  CONTAIN 

INITIALIZATION  VALUES  ! 

006C 

A10F 

ID 

R15,  R0  'RESTORE  SP! 

006E 

97F0 

POP 

30,  0R15  ! RESTORE  ARGUMENT  PTP.! 

0070 

A1FE 

LD 

R14,  R15  !SAV£  CALLER  RETURN  POIN 

0072 

A10F 

LD 

Rib,  R0  !GET  ARGUMENT  PTP! 

0074 

1CF1 

LDM 

R3 ,  0815,  *4  SLOAD  ARGUMENTS! 

0076 

0303 

0078 

341F 

LDA 

Rib,  R1(#INTERRUPT_FRAME) 

007A 

00EC 

007C 

1CF9 

LDM 

0816,  R3,  #2  UNIT  IRST  FRAME! 

007E 

0301 

oeee 

341F 

LDA 

R15 ,  R1(#N_S_?) 

0e92 

00C8 

0084 

2FF5 

LD 

0815,  R5  ! SET  NSP! 

0086 

030F 

SUB 

Rib,  *2 
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ID 

IDA 


1 


0088  0002 
008 A  2FF6 
008C  3418 
008E  00F0 

0080  2100 
0082  5000 
0094  ice9 
0096  0F01 
0098  AlEF 
009 A  9E08 
009C 

END 


G»R15,  R6  ! PREEMPT  RET  POINT 
R8 «  Rl(#STACK_BASE) 


j 


!  initialize  status  REGISTER  BLOCK  ! 


ID 

R0  ,  #KERNi’I_FC ’* 

I  DM 

0H6,  R15, 

*2  ’SAVE  SP  A 

TC'*'. 

LD 

R15,  R14 

! RESTORE  RETURN 

POINT! 

RET 

END  CREATE  STACK 
LIBRARY  FUNCTION 


APPENDIX  G  -  INNER  TRAFFIC  CONTOIIER  LISTINGS 


ZfcCfcfcJASM  2.H2 

LOC  OBJ  CODE  STMT  SOURCE  STATEMENT 

INNER_TRAFFIC_CONTROL  MODULE 
HISTON  $TTY 
!^1.  GETWORK: 

A.  NORMAL  ENTRY  DOES  NOT  SAVE  REGISTERS. 

(  THIS  IS  A  FUNCTION  OF  THa  GATEKEEPER  ). 

B.  R14  IS  AN  INPUT  PARAMETER  TO  GETWORK  THAT 
SIMULATES  INFO  THAT  WILL  EVENTUALLY  BE  ON 
THE  MMU  HARDWARE.  THIS  REGISTER  MUST  EE 
ESTABLISHED  AS  A  DBR  EY  AM  PROCEDURE 
INVOKING  GETWCRK . 

C.  THE  PREEMPT  INTERRUPT  ENTRT  HANDIER  DOES 
NOT  USE  THE  GATEKEEPER  AND  MUST  PERFORM 
FUNCTIONS  NORMALLY  ACCOMPLISHED  BY  IT 
PRIOR  TO  NORMAL  ENTRY  AND  EXIT. 

(  SAVE/RESTORE:  REGS,  NSPJ  UNLOCK  VPT,  TEST  I  NT ) 

2.  GENERAL: 

A.  ALL  VIOLATIONS  OF  VIRTUAL  MACHINE  INSTRUCTIONS 
APE  CONSIDERED  ERROR  CONDITIONS  AND  WILL  RETURN 
SYSTEM  TO  THE  MONITOR  WITH  AN  ERROR  CODE  IN  RV 
AND  THE  PC  VALUE  IN  R1 . 

B.  ITC  PROCEDURES  CALLING  GETWORK  PASS  DPR 
(REGISTER  R14)  AND  LOGICAL  CPU  NUMBER 
(REGISTER  R13 )  AS  INPUT  PARAMETERS. 

(INCLUDES:  SIGNAL,  WAIT,  SWAP  VD£P, 

PHYS_PREEMPT_HANDLER ,  AND  IDLE  ^ .  ! 

CONSTANT 

i  vvwvwwv  ERROR  CODES  wwvwvwm  ; 


U  L 

= 

e 

!  UNAUTHORIZED  LOCK  ! 

M  L  EM 

S 

1 

!  MESSAGE  LIST  EMFTY  ! 

M  L“ER 

= 

2 

!  MESSAGE  LIST  ERRC’5  ! 

p.“l"e 

s 

3 

!  READY  LIST  EMPTY  ! 

M  L  0 

= 

4 

!  MESSAGE  LIST  OVERFLOW 

SNA 

= 

5 

!  SWAP  NOT  ALLOWED  ! 

V  I_E 

s 

6 

!  VP  INDEX  ERROR  ! 

M  U 

s 

7 

!  MMU  UNAVAILABLE  ! 

f  *«V  WWW 

NR  SDR 
NR"CPU 

NR"  VP 

SYSTEM  PARAMETERS  ********  f 
:*  64  l LONG  WORDS! 

:  =  2 

:=  NR  CFU*4 

N?._AVAIL. 

.VP 

: =  NR_CPU*2 

MAX  DBP  NR  :=  1 0  !PER  CPU! 

STACK.  SEG  :  *  1 

PRDS  SEG  :=  0 

STACl_SFG_SIZE  :=  *100 

j  *****  OFFSETS  IN  STACK  SEG  *****  ! 

STACK  BASE  :=  STACK  SEG  SIZE-*10 

STATUS  REG  BLOCK: =  STACK'S  EG  SIZE-*10 
INTERRUPT  FRAME  :=  STACK”BASE-4 
INTERRUPT"REG  :*  INTERRUPT  FRAME-34 
N_S  P  “  :=  lNTERRUPT*”REG-2 

F_c”w  :*  STACK_S£G~SIZE-*E 

ON  :=  *FFFF 

OFF  :=  0 
RUNNING  :=  e 
READY  :=  1 
WAITING  :=  2 
NIL  :=  *FFFF 
INVALID  :=  %EEEE 

MONITOR  :=  *A900  !  H3UG  ENTRY  ! 

KERNEL  FCW  :=  *5000 
AVAILABLE  :=  0 
ALLOCATED  :=  *FF 

TYPE 

MESSAGE  ARRAY  116  BYTE] 

ADDRESS  WORD 

VP  INDEX  INTEGER 

MSG__INDEX  INTEGER 

SEG  DESC  REG  RECORD 

t 

BASE  ADDRESS 

ATTRIBUTES  BYTE 

LIMITS  BYTE 

i 

MMU  ARRAY fNR_SDR  S£G_DESC_REGJ 

MSG  TABLE  RECORD 
[  MSG  MESSAGE 

SENDER  VP  INDEX 

NEXT  MSG  MSG  INDEX 

FILLER  ARRAY  [6,  rfORDJ 

J 
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0000 


0210 


0000 


0A00 

0A0A 


VP  TABLE  RECORD 
"  [  DBR  ADDRESS 

PHI  WORD 

STATE  WORD 

IDL£_FLAG  WORD 

PREEMPT  WORD 

PHIS  PROCESSOR  WORD 

NEXT~R£ADY  VP  VP  INDEX 

MSG  LIST  MSG  INDEX 

EXT~ID  WORE 

FILLER  1  ARRAY  l?,  WORE] 


EXTERNAL 
LIST  INSERT 


PROCEDURE 


GLOBAL 

BOOTS TRAP_EN TRY  LABEL 

$SECTION  1TC_DATA 

VPT  RECORD 

[  LOCK  WORD 

RUNNING  LIST  ARRAY  [  NR_CP(J  WORD] 

READY  LIST  ARRAY [NR~CPU  WORD] 

FREE  LIST  MSG  INDEX 

VIRT~INT  VEC  ARRAY  [1,  ADrRESSJ 
FILLER  2  WORD 

VP  "  ARRAY  L NR  VP,  VP  TABLSJ 
MSG  0  ARRAY  INR  VP.'mSG  TAiLEJ 

J 

EXT_VP  LIST  ARRAY L NR  AVAIL  VP  WORDJ 


SSECTION  MMU  DATA 


MMU  IMAGE  RECORD 

"[ 

MMU  STRUCTURE  ARRAY  [MAX  DBR  NR  MMUJ 

J 

NEXT  AVAIL  MMU  ARRAY TmaX  DBR  NR  BYTEJ 
PRDS"  RECORD 

IPHYS  CPU  ID  WORD 
LOG  CPU  ID  INTEGER 
VP  NR  WORD 

IDLE  VP  VP  INDEXJ 
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^SECTION  ITC_INT_PROC 
INTERNAL 

0000  GETWORK  PROCEDURE 

I  «yw***«*>ll***f*********>|i**W**** 

*  SWAPS  VIRTUAL  PROCESSORS  * 

*  ON  PHYSICAL  PROCESSOR.  * 

vvw«*f**yy*>i<m**vvv********** 

*  PARAMETERS:  * 

*  R13:  LOGICAL  CPU  #  * 

*  REGISTER  USE:  * 

*  STATUS  REGISTERS  * 

*  R14:  DBR  (SIMULATION)  * 

*  R1&:  STACK  POINTER  * 

*  LOCAL  VARIABLES:  * 

*  Rl:  READ!  VP  (NEW)  * 

*  R2 :  CURRENT  VP  (OLD)  * 

*  R3:  FLAG  CONTROL  WORD  * 

^  R4 :  STACK  SEG  EASE  ADDR  * 

*  R5:  STATUS  REG  BLOCK  ADDR  * 

*  R6:  NORMAL'S? ACK  POINTER  * 

ENTRI 


!  GET  STACK  BASE  ! 


0000 

31E4 

LD 

R4, 

R14(#STACK_SEG*4) 

0002 

0004 

0004 

3445 

LDA 

R5, 

R4(#STATUSJiEG_BL0CK) 

0006  00F0 

!  *  *  SAVE  SP  *  *  ! 

0008  2F5F  LD  PR5 .  R15 

!  *  *  SAVE  FCW  *  v  ! 

000A  7D32  LDCTL  R3,  FCW 

000C  3343  LD  R4(#F  C  W),  R3 

000S  00F2 

BOOTSTRAP  ENTP t :  !  GLOBAL  LABEL  ! 

!  GET"READT_VP  LIST  ! 

0010  61D1  ID  HI,  VPT.READY_LIST(R13) 

0012  0006' 

SSL  EC  T  V  P ; 

DO  ! “UNTIL  BLGIELE  READY  VP  FOUND  ! 

0014  4D11  CP  VPT .  VP  .IDLE  FLAG( FI ) ,"*ON 
0016  0016' 

0018  FFFF 

001A  5E0E  IF  EC  !  VP  IS  IDLE  !  THEN 
001C  0030' 

001S  4D11  C?  VPT. VP. PREEMPT ( Rl ) ,  »CN 

0020  0018' 

0022  FFFF 

0024  5E0E  IF  EO  !  PREEMPT  INTEFRUPT  IS  ON  !  THEN 
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002b 

002C  ' 

0028 

SE09 

EXIT  FROM  SELECT_VP 

002A 

003C  ' 

FI 

002C 

5E08 

ELSE  !  VP  NOT  IDLE  I 

002E 

0034' 

0030 

5E08 

EXIT  FROM  SELECTOR 

0032 

003C ' 

FI 

!  GET  NEXT  READY  VP  ! 

0034 

6113 

LD  R3 ,  VPT.VP.NEXT_READI 

0036 

001C  ' 

0036 

A131 

LD  Ri,  R3 

003A 

E6EC 

CD 

!  NOTE:  THE  READY  LIST  WILL  NEVER  BE  EMPTY  SINCE 
THE  IDLE  VP,  WHICH  IS  THE  LOWEST  PRI  VP, 

WILL  NEVER  BE  REMOVED  FRO?*  THE  LIST. 

IT  WILL  RUN  ONLY  IF  ALL  OTHER  READY  VP'S  ARE 
IDLING  OR  IF  THERE  ARE  NO  OTHEP  VP'S  ON 
THE  READY  LIST.  ONCE  SCHEDULED,  IT 

will  run  Until  receiving  a  hbwe  interrupt,  i 


!  NOTE:  R14  IS  USED  AS  DPR  HERE.  WHEN  MMU 

IS  AVAILABLE  THIS  SERIES  OF  SAVE  AND  LOAD 
INSTRUCTIONS  WILL  PE  REPLACED  PI  SPECIAL  I/C 
INSTRUCTIONS  TO  THE  MKU.  ! 


003C 

4ri5 

LD 

VPT. VP.STATE(Rl) ,  ^RUNNING 

003E 

0014' 

0040 

0000 

0042 

6FD1 

LD 

VPT.?UNNING_LIST(R13) ,  Rl 

0044 

0002' 

!  * 

*  SWAP  DBF  *  *  ! 

0046 

6  HE 

LD 

R14 •  VPT.VP.DBR(Rl) 

0048 

0010 ' 

I  LOAD  NEW  VP  SP  !  j 

004A 

31E4 

LD 

R4,  R14(#STACK_SEG*4 ) 

004C 

0004 

004E 

3445 

LDA 

P5»  P.4 (# STATUS _REG_ BLOCK  ) 

00b0 

00F0 

0052 

215F 

LD 

Rl5,  0R5 

!  * 

*  LOAD  NSW  FCW  *  *  ! 

0054 

3143 

LD 

R3.  R4(#F_C_W) 

0056 

00F2 

0058 

7D3A 

LDCTL  FCW,  R3 

005A 

9E08 

RET 

005C 

END  GET WORK 

igy 


J 


M*- 


ee5C  SNTBR_>MSG_LIST  PROCEDURE 

*  INSERTS  POINTER  TO  MESSAGE  * 

*  FROM  CURRENT  VP  TO  SIGNALED  VP* 

*  IN  FIFO  MSG_LIST  "  * 

«  VV  ¥  W  M  «B»  ft  V  M  W  W  »  V  M  W  VM  V  V  V  >*  V  W  V 

*  REGISTER  USE:  * 

*  PAPAMETERS:  * 

*  R8(R9):MSG  (INPUT)  * 

*  Rl:  SIGNALED  VP  (INPUTS  * 

*  PI 3:  LOGIC Al~CPU  NUMBER  * 

*  LOCAL  VARIABLES:  * 

*  R2 :  CURRENT  VP  * 

*  R3 :  FIRST  FREE  MSG  * 

*  R4 :  NEXT  FREE  MSG  * 

*  R5 :  NEXT“0  MSG  * 

*  R6 :  PRESENT__0_MSG  * 

SNTRX 

005C  61D2  ID  R2,  VPT.RUNNING_LIST(R13 ) 
005E  0002  ' 


!  GET  FIRST  MSG  FROM  FREE  LIST  ! 
0060  6103  LD  R3,  VPT.FFJSE  LIST 
0062  000A ' 


0064  0B03 
0066  FFFF 
0068  5E0E 
006A  0079' 
006C  7601 
006E  006C  ' 
0070  2100 
0072  0004 
0074  5F00 
0076  A900 


!  *  *  *  *  DEBUG  *  *  *  *  ! 

CP  R3 «  #NIL 

IF  EC  THEN 

IDA  PI,  S 

LD  R0 ,  #M_L_0!  MESSAGE  LIST  OVERFLOW  ! 
CALL  MONITOR 
FI 

!  *  *  *  END  DEBUG  *  *  *  ! 


0078 

6134 

LD 

R4, 

VPT.MSG_Q.NEXT 

_MSG(R3^ 

007A 

0122' 

007C 

6T04 

ID 

VPT . 

FBEE_LI ST ,  R4 

007E 

000A ' 

!  INSERT 

MESSAGE  LIST 

INFORMATION 

0080 

763A 

LDA 

R10 ,VPT.MSG_ 

0 .MSG (R3 ) 

0082 

0110' 

0084 

2107 

LD 

R?,#S IZEOF  MESSAGE 

00ee 

0010 

0088 

BA81 

LDIRB 

0R10 ,9R8 ,R7 

008  A 

07A0 

200 


008C  6F32  LD  VPT.MSG  0  .  SENDER  ( R3  ) ,  R2 
008E  0120' 

!  INSERT  MSG  IN  MSG  LIST  ! 

0090  6115  LD  R5,  V?T.VP.MSG_LIST(R1) 

0092  0015' 

0094  0E05  C?  R5,  #NIL 

0096  FFFF 

0098  5E0S  IF  £0  !  *SG  LIST  IS  EMPTY  !  THIN 

009A  0eA4' 

!  INSERT  MSG  AT  TOP  OF  LIST  ! 

009C  6F13  ID  V??. VP. MSG  LlST(Rl),  R3 
009E  0015' 

00A0  5E08  ELSE  !  INSERT  MSG  IN  LIST  ! 

00A2  00BC ' 

MSG_0  SEARCH: 

DO  !“'HHILE  NOT  END  OF  LIST  ! 

00A4  0B05  CP  R5,  »NIL 

00A6  FFFF 

00A8  5E0E  IF  EO  !  END  OF  LIST  !  THEN 

00AA  00B0 ' 

00AC  5E08  EXIT  FROM  MSG  C  SEARCH 

00AE  0038' 

FI 


!  GET  NEXT  LINE  ! 


00B0 

A156 

LD 

R6,  R5 

00B2 

6165 

LD 

R5,  VPT . MS G_0 . NE XT_MS G ( R6 ) 

00B4 

ei22' 

00B6 

S8F6 

OD 

!  INSERT 

MSG  IN  LIST  ! 

00B8 

6F63 

ID 

VPT.MSG_O.NEXT_MSG( 86) .  32 

003  A 

0122' 

FI 

00BC 

6F35 

LD 

VPT.MSG_0.NEXT_MSG(R3U  Pft 

00BE 

0122' 

00C0 

9E0e 

RET 

00C2 

END  ENTER  MSG  LIST 

201 


euC2 


eec2  6iD2 
00C4  0002' 


GET_FIRST_MSG  PROCEDURE 

I  vvxfiwww# **** ******* ww* 

*  REMOVES  MSG  FROM  *SG  LIST  v 

*  AND  PLACES  ON  FREE  LIST.  * 

*  RETURNS  SENDER'S  MSG  AND  * 

v  fp  id  ^ 

^REGISTER  USE:  * 

*  PARAMETERS :  v 

*  Re(Ry):  MSG  POINTER  (INPUTS  * 
m  R13:  LOGICAL  CPU  NUMBER  (  INPUT)* 


* 

Rl: 

SENDER  VP  (RETURNED) 

* 

V 

LOCAI 

,  VARIABLES 

V 

V 

R2 : 

CURRENT  VP 

V 

* 

R3 : 

FIRST  MSG 

* 

* 

R4 : 

NEXT  MSG 

* 

R5 : 

NEXT  FREE  MSG 

* 

R6 : 

PRESENT  FREE  MSG 

* 

***********************************  I 

ENTRr 

LD  R2,  VPT.RUNNING_LIST(R13) 


!  REMOVE  FIRST  MSG  FROM  MSG_LIST  ! 
00C6  6123  ID  R3,  VPT.VP.MSG  LIST(R2) 

00C8  001E' 


0-0 C A  0B03 
00CC  FFFF 
00CE  5E0E 
00D0  eeDE' 
00D2  2100 
00D4  0001 
00D6  7601 
00D9  00D6  ' 
00DA  5F00 
00DC  A900 


00DE  6134 
00E0  0122' 
00E2  6F24 
00E4  001E ' 

00E6  6105 
00E8  000A ' 
00EA  0B05 
00EC  FFFF 
00EE  5E0E 
00F0  0100' 


!  *  *  *>  *  DEEUG  »  *  v  *  ! 

CP  R3,  #NIL 

IF  EQ  THEN 

LD  P0,  #M_L_EM  !  MSG  LIST  FMFT 
LDA  Rl,  $ 

CALL  MONITOR 
FI 

«  *  *  *  END  DEBUG  *  *  *  ! 


LD 

R4,  VPT.MSG_C.NEXT_MSG(R3) 

LD 

VPT.VP.MSG_LlSTfR2) ,  R4 

!  INSERT  MESSAGE  IN  FREE  LIST 

LD 

R5,  VPT.FREE_LIST 

CP 

R5,  #NIL 

IF  EO 

!  FREE_LIST  IS  EMPTY  !  THEN 
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fl 


00F2  6f  03 
00F4  e00A' 
00F6  4D35 
00F8  0122' 
00FA  FFFF 
00FC  5E08 
00FE  011C' 


!  INSERT  AT  TOP  OF  LIST  ! 

LD  VPT . FREE_LIST ,  S3 

ID  V?T.MSG_C.NEXT_MSG(R3) ,  *NIL 

ELSE  !  INSERT  IN  LIST  ! 

FREE  C  SEARCH: 

BO 

CP  R5 ,  *NIL 

IF  EO  !  END  OF  LIST  !  THEN 
EXIT  FROM  FRSE_0_>S£ARCH 


R6,  Rb 

R5 ,  VPT.MSG_C.NEXT_MSG(R6) 


0100 

0505 

CP 

0102 

FFFF 

0104 

5E0E 

IF  EO 

0106 

010C' 

0108 

5E08 

EXIT 

010  A 

0114' 

FI 

!  GET 

010C 

A156 

LD 

010E 

6165 

LD 

0110 

0122' 

0112 

E8F6 

OD 

!  INSERT 

0114 

6F63 

LD 

0116 

0122' 

0118 

6F35 

LD 

011A 

0122' 

VPT.MSG_Q.NEXT_MSG(R6) ,  R3 
VPT . MSG_0 .  NeXT_MS  G ( R3 ) ,  Rb 


!  GET  MESSAGE  INFORMATION: 
(RETURNS  Rl:  SENDING  VP)  ! 


011C 

6131 

LD 

Rl,  VPT. MSG 

_0 .S  ENDER ( 

011E 

0120' 

0120 

763A 

LDA 

R10  ,VPT.MSG 

_0.MSG(R3) 

0122 

0110' 

0124 

2107 

LD 

R 7,#SIZEOF 

MESSAGE 

0126 

0010 

0128 

BAA1 

LDIRB 

(*Re,(*ai0,R7 

012A 

0780 

012C 

9E08 

RET 

012E 

END  GET 

FIRST  MSG 

!  *  *  INNER  TRAFFIC  CONTROL  ENTRY  FOINTS  *  *  ! 


0000 


0000 

0002 


0004 

000(3 

0000 

000A 


!  NOTE:  ALL  INTERRUPTS  MUST  BE  MASK  EC  WHENEVER 
THE  VPT  IS  LOCKED.  THIS  IS  TO  PREVENT  AN 
EMBRACE  FROM  OCCURRING  SHOULD  AN  INTERRUPT 
OCCUR  WHILE  THE  VPT  IS  LOCKED.  ! 

GLOBAL 

SSECTION  ITC_GLB_PROC 

PREEMPT  RET  LABEL 
KERNEL  EXIT  LABEL 
CREATE2INT_VEC  PROCEDURE 

*  CREATES  ENTRY  IN  VIRTUAL  I NT-* 

*  ERRUPT  VECTOR  WITH  ADDRESS  * 

*  OF  THE  VIRTUAL  INTERRUPT  HAN-* 

*  DLER .  * 

its*  vw  wvvvvovv  vw  www  w*f  w*r  wv 

*  PARAMETERS:  * 

*  El :  VIRTUAL  INTERRUPT  #  * 

*  R2 :  INTERRUPT  HANDLER  ADDR  v 

***wv*********v*«*«v*f(4iy**i|i«iv**  I 

ENTRY 

!  COMPUTE  OFFSET  IN  VIRTUAL 
INTERRUPT  VECTOR  ! 

1900  MULT  RR0 ,  #SIZE0F  ADDRESS 

0002 

!  SAVE  ADDRESS  OF  VIRTUAL  INTERRUPT 
HANDLER  IN  INTERRUPT  VECTOR  ! 

6F12  LD  VPT.VIRT  INT  VEC(Rl),  R2 

000C  ' 

9E0S  RET 

END  CREATE  INT_VEC 


eee a  get  dbr  aedr  procedure 

f  VVWWWVVVVillWXtVViilVWVVWWWVW 

*  CALCULATES  DER  ADDRESS  FROM  * 

*  DBR  NUMBER  * 


*  REGISTER  USE:  * 

*  PARAMETERS :  * 

*  ?0:  DBF.  *  * 

*  RETURNS:  * 

*  Rl:  DBR  ADDRESS  * 


vm*  t?***)?*)***  v*  «>***>*«  j 

ENTR'r 

!  GET  BASE  ADDRESS  OF  MMU  IMAGE  * 

000A  7601  IDA  Rl,  MMU  IMAGE 

000C  0000' 

!  ADD  DBR  HANDLE  ( OFFSET >  TO  MMU  BASE 
ADDRESS  TO  OBTAIN  DBR  ATDRESS  ! 

000E  8101  ADD  Rl,  R0 

0010  9E08  RET 

0012  END  GET  DBR  ADDS 


0012  ALLOCATE  MMU  PROCEDURE 

I  j*«W****w*VV«9«**V*V****«Wig'V*9«i* 

**  ALLOCATES  NEXT  AVAILABLE  MMU  * 
»  IMAGE  ANI  CREATES  PRES  ENTRY  * 


¥ 

REGISTER  USE: 

¥ 

¥ 

RETURNS : 

¥ 

¥ 

R0 :  DBR  # 

¥ 

¥ 

LOCAL  VARIABLES: 

¥ 

¥ 

HI:  SEGMENT  # 

¥ 

¥ 

R2 :  PHDS  ADDRESS 

¥ 

¥ 

R3 :  PP.DS  ATTRIBUTES 

¥ 

¥ 

R4 :  PRDS  LIMITS 

¥ 

««*n*y***v*«*««***vv9!nmv>iiv #*v  t 


ENTRT 

!  GET  NEXT  AVAILABLE  DER  *  ! 


0012 

SD08 

CLP. 

R0 

0014 

8D18 

CLR 

Rl 

!  NOTE:  THE  FOLLOWING  IS  A  SAFE  SEQUENCE 

AS 

NEXT 

_AVAIL_MMU  AND  MMU  ARE  CPU  LOCAL! 

GST 

DBR: 

'DO 

0016 

4C11 

CPB 

NEXT_AVAIL_MMU(Rl) ,  #AVAILABLE 

0018 

0A00' 

eeiA 

0000 

IF 

EO 

!  MMU  ENTRY  IS  AVAILABLE! 

001C 

5E0E 

THEN 

001E 

002E  ' 

0020 

4C15 

LDB 

NEXT_AVAIL_MMU(R1 } ,  ^ALLOCATED 

0022 

0A00  ' 

0024 

FFFF 

0026 

5E08 

EXIT 

from  get_def 

0028 

004A  ' 

002A 

5E08 

ELSE 

! CURRENT  ENTRY  IS  ALLOCATED! 

002C 

0048' 

002E 

A910 

INC 

Rl,  #1 

0030 

0100 

ADD 

R0 ,  #S IZEOF  MMU 

0032 

0100 

I  v 

*  v  #  DEBUG  *  *  *  *  ! 

0034 

0E01 

CP 

HI,  #MAX_DBR_NR 

0036 

000A 

0038 

5E0E 

IF 

EO  THEN 

003A 

0048' 

003C 

2100 

LD  R0 ,  #M_TJ  !  MMU  UNAVAILABLE 

003E 

0007 

0040 

7601 

LDA  Rl,  S 

0042 

0040' 

0044 

5F00 

CALL  MONITOR 

0046 

A900 

FI 

!  *  *  w  END  DEBUG  *  *  *  ! 


| 


FI 

0048  E6E6  OD 


004A 

2101 

LE 

P-1, 

#PRDS_SEG 

!  SEGMENT  NO 

0e4C 

0000 

004E 

7602 

irA 

R2, 

PRDS 

!  PRDS  ADDR 

0050 

0A0A  ' 

0052 

2103 

ID 

R3, 

»1  !  READ 

ATTR  ! 

0054 

0001 

PRDS )-l)/256 

0056 

2104 

ID 

R4, 

#(  (SIZEOF 

0058 

0000 

!  PRDS 

LIMITS 

I 

!  CREATE  PRDS  ENTRY  IN  MMU  IMAGE  ! 

005A  5F00  CALI  OPDATE_MMU_ IMAGE  !(R1:  SEGMENT  * 

005C  0060' 

R2:  SEG  ADDRESS 
R3 :  ATTRIBUTES 
R4  :  SEG  LIMITS ) ! 

005E  9E08  RET 

0060  END  ALLOCATE  MMU 


r 


0060  UPDATE_MMU_ IMAGE  PROCEDURE 

*  CREATES  SEGMENT  DESCRIPTOR  * 

*  entry  in  mmu  image  * 


¥ 

REGISTER  USE: 

>91 

* 

PARAMETERS: 

R0 :  DBR  # 

* 

* 

Rl:  SEGMENT  # 

V 

* 

R2:  SEGMENT  ADDRESS 

V 

a? 

R3 :  SEGMENT  ATTRIBUTES 

V 

* 

R4 :  SEGMENT  LIMITS 

* 

* 

LOCAL  VARIABLES: 

m 

R10 :  MMU  EASE  ADDRESS 

*A 

* 

R13 :  OFFSET  VARIABLE 

ipwaiugtwwwwv’e'v’i'wipwwvww***  | 


ENTPT 


0060 

210A 

LD 

R10 ,  #MMU_IMAGE  f  MMU  BASE  AEDRESS  J 

0062 

0000' 

0064 

810A 

ADD 

R10 ,  R0 

0066 

210D 

LD 

R13*  #S IZEOF  SEG_DESC_REG 

006B 

0004 

006A 

991C 

MULT 

RR12 ,  Rl  !  COMPUTE  SEG  DES.C  OFFSET 

eeec 

81DA 

ADD 

R10 ,  R13  ! ADD  OFFSET  TO  BASS  ADDRESS 

!  INSERT  DESCRIPTOR  DATA  ! 

006E 

2FA2 

LD 

GR10,  R2 

0070 

A9A1 

INC 

R10,  #2 

0072 

0DA8 

CLR 

GR10 

0074 

2EAC 

LDB 

GR10,  RL4 

0076 

A9A0 

INC 

R10.  #1 

0078 

20AC 

LDB 

RL4,  PR10 

007  A 

0A0B 

CPB 

RL3,  ^(2)00001000  !  EXECUTE  ! 

007C 

0808 

007E 

5E0S 

I? 

EQ  TEEN 

0080 

008A  ' 

0032 

06  0C 

ANDB  RL4 ,  #3(2)11110111  !  EXECUTE  * 

0084 

F7F7 

0086 

5E08 

ELSE 

0088 

008E  ' 

008A 

060C 

ANDB  RL4 ,  #3(2)11111110  !  READ  *ASK 

008C 

FEFE 

FI 

008E 

84BC 

ORB 

RL4,  RL3 

0090 

2EAC 

LDB 

GR10 ,  RL4 

0092 

9E0e 

RET 

0094  END  UPDATE_MMU_IMAGE 


ee94 


WAIT  PROCEDURE 

*  INT’A_KERNEL  STNC/COM  PR  IMATIVE  * 


*  INVOKID  BY  KERNEL  PROCESSES  * 

*  PARAMETERS  * 

*  R8(R9):  MSG  POINTER  (INPUT)  * 

*  R1 :  SENDING  VP  (RETURN)  * 

*  GLOBAL  VARIABLES  * 

*  R14 :  LBR  (PARAM  TO  GETVORK )  * 

*  LOCAI  VARIABLES  * 

*  R2 :  CURRENT  VP  (RUNNING;  » 

*  R3 :  NEXT  READY  VP  * 

*  R4 :  LOCK-ADDRESS  * 

*  R13 :  LOGICAL  CPU  NUMBER  * 


m«**»********9»¥***«*«y**in*****¥* ! 

ENTRY 

»  MASK  INTERRUPTS  I 
ce94  7C01  DI  VI 

j  LOCK  VPT  ! 

0096  7604  LDA  R4,  VPT. LOCK 

0098  00 00 ' 

009 A  5F00  CALL  SPIN  LOCK  !  (R4  :~VPT  .LOCK)  ! 

009C  0282  * 

!  NOTE:  RETURNS  WHEN  VPT  IS  LOCKED  BY  THIS  VF  ' 

!  GET  CPU  NUMBER  * 

009 E  5F00  CALL  GET  CPU  NO  (RETURNS: 

00A0  02C6 ' 

Pi: CPU  9 
R2  :#  VP'S! 

00A2  A11D  LD  R13 ,  Rl 

00A4  61D2  LD  R2 ,  VPT  .RUNNING  LIST(R13) 

00A6  0002' 

Z0Ae  6123  Lr  53,  VPT. VP. NEXT  READY  V?(R2' 

00AA  001C' 

00AC  4D21  CP  VPT. VP. MSG  LIST(R2),  #NIL 

00AE  001E ' 

00B0  FFFF 

00B2  5E0E  IF  EC  !  CURRENT  VP'S  *SG  LIST  IS  EMPTV  !  THEN 
00B4  00EA ' 

!  REMOVE  CURRENT  VP  FROM  READY  LIST  ! 

!  r*  *  •!•■"*!*  DEBUG  *  v  t 

00B6  0B03  CP  R3 ,  #NIL 

00B8  FFFF 

00BA  5E0E  IF  EO  THEN 

00BC  00CA ' 

003E  2100  LD  R0 ,  #P.  L  E  !  READY  LIST  EMFTY  ! 

00C0  0003 

00C2  7601  IDA  Rl,  A 


eec4  0002' 

00C6  5F00  CALI  MONITOR 

00C8  A900 

FI 

1  *  *  *  END  DEBUG  *  *  *  ( 

00C A  6FD3  LD  VPT. READY  LIST(R13),  P.3 

00CC  00eb' 

00CE  4D25  LD  VPT.VP.NEXT  READY  VP(R2K  *NIL 

00D0  001C' 

00D2  FFFF 


00D4  4D25 
00D6  0014' 
00D8  0002 

00DA  6 12E 
00DC  0010' 

00DE  93F8 

00E0  93FD 
00E2  5F00 
00E4  0000' 


00E6  97FD 
00E8  97F8 


00EA  5F00 
00EC  00C2 ' 


!  PUT  IT  IN  WAITING  STATE  ! 

LD  VPT.VP.STATE(32)  ,  ^WAITING 


!  SET  DER  ! 

LD  314,  VPT.7P.rf R(R2> 

!  SCHEDULE  FIRST  ELGIBLa  READV  VP  ! 

PUSH  0R15.RB 

!  SAVE  LOGICAL  CPU  #  ! 

PUSH  tiRlb,  313 

CALL  GETWOP.K  !R13:C?U  * 

R14 :  D£R ! 

!  RESTORE  CPU  #  ! 

POP  R13,  PP.15 

POP  R8,  PP.15 

FI 

!  GET  FIRST  MSG  CN  CURRENT  VP'S  LIST  ! 
CALL  GET_FIRST_MSG  !  COPIES  MSG  IN  MSG  APRA  v 

!  R13:  LOGICAL  CPU  ft  ! 
’.RETURNS  Rl :  SEN  LEP  V?  ! 


!  UNLOCK  VPT  ! 

00EE  4D08  CIR  VPT. IOCE 
00F0  0000' 

!  UNMASK  VECTORED  INTERRUPTS  ! 
00F2  7C05  El  VI 


!  RETURN:  Rl :SENDE3  VP  ! 
00F4  9E08  RET 
00F6  END  WAIT 


vert)  SIGNAL  PROCEDURE 

f  wwtjCJZVWWWWMWWWfWWWWWVW 

*  INTRA  KERNEL  SYNC  /CO M  PR  IMATIVE  * 

»  INVOKED  by  kernel  processes  * 


V  REGISTER  USE: 

*  PARAMETERS: 

*  Re(Ry):  MSG  POINTER  (INFUT) 

*  Ri:  SIGNALED  VP  ID  (INPUT) 

*  GLOBAL  VARIABLES 


v 

9 

V 

V 
* 


Jft 

R13 : 

CPU  #  (PARAM  TO  GETWORK) 

V 

R14 : 

DER  (PARAM  TO  GETWORK) 

V 

# 

LOCAL 

,  VARIABLES: 

V 

Rl : 

SIGNALED  VP 

s* 

R2 : 

CURRENT  VP 

V 

m 

R4 : 

VPT. LOCK  ADDRESS 

VMS  WWW  WWW  W  WM  W  **»»»»M*  f 

ENTR'V 

!  SAVE  VP  ID  ! 


00F6 

93E1 

PUSH 

PR15 ,  Rl 

!  MASK 

INTERRUPTS  ! 

00F8 

7C01 

PI 

VI 

!  LOCK 

VPT  ! 

00FA 

7604 

LDA 

R4,  VPT.LOCK 

MFC 

0000' 

00FK 

5F00 

CALL 

SPIN_LOCK  !  (R4  :~</PT .  LOCK '  ! 

0100 

0282' 

! NOTE : 

RETURNS  WHEN  VPT  IS  LOCKEr  3Y  THIS 

!  GET 

LOGICAL  CPU  #  ! 

0102 

5F00 

CALL 

GET_CPU_N0  'RETURNS: 

0104 

02ce' 

Rl : CPU  * 

R2 : *  VP'S! 

0106 

A11D 

LD 

313,  31 

!  RESTORE  VP  ID  ! 

0108 

97F1 

POP 

Rl,  0R15 

!  PLACE  MSG  IN  SIGNALED  VP'S  MSG  LIST  ! 

010A 

5F00 

CALL  ENTER  MSG  LIST  !(P8:MSG  POINTER 

010C 

005C  ' 

Rl  SIGNALED  VF 

R13: LOGICAL- CPU  s' 

010E 

4D11 

CP 

V?T.VP.STATE(R1  )  ,  ^WAITING 

0110 

0014' 

0112 

0002 

0114 

5E0E 

IF  SO 

!  SIGNALED_VP  IS  WAITING  !  THEN 

0116 

0148' 

t  WAKE  IT  UP  AND  MAKE  IT  READY  ! 

one 

A112 

LD 

R2,  Rl 

011A 

76D3 

LDA 

R3,  VPT. READY  LIST(RIZ) 

VP. 
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011C  0006' 
0112  7604 
0120  001C' 
0122  7605 
0124  0012' 
0126  7606 
0128  0014' 
012A  2107 
012C  0001 

012E  93FD 
0130  5F00 
0132  0000* 


0134  97FD 

0136  61D2 
0138  0002' 
013A  4D25 
013C  0014' 
013E  0001 

0140  612E 
0142  0010' 


LDA 

R4, 

VPT.VF.NEXT_REaD1_VP 

IDA 

R5. 

VPT .VP. PR  I 

LDA 

Rti, 

VPT. VP. STATE 

LD 

R7, 

#RSADY 

!  SAVE  LOGICAL  CPU  # 
PUSH  yp.15,  P.13 

CALI  LIST  INSERT 


!R2: 

OJ«J  ID 

R3 : 

LIST  PTP.  AEDP 

R4 : 

NEXT  OPJ  PTR 

R5 : 

prioSity”?tp. 

R6 : 

STATE  PTR 

R7 : 

STATE  ! 

!  RESTORE  LOGICAL  CPU 
POP  R13 ,  GP15 

!  PUT  CURRENT  VP  IN  READ7  STATE  ! 
LD  R2,  7PT. RUNNING  IlST(R13s 


LE  7PT. VP. STATE ( R2  )  ,  eREAEY 


!  SET  D5R  ! 

ID  P.14  .  VPT .  VP .  DPR  (  R2  ^ 


0144  5F00 
0146  0000' 


!  SCHEDULE  FIRST  ELGIPLE  READY  VP  f 


CALL  GETiOP.K 

FI 


!R13  :IOGIC  aL  CPU  * 
P14 :DER  ! 


!  UNLOCK  VPT  ! 

0148  4D08  CLP  VPT. LOCK 
014A  0000' 

■  UNMASK  VECTORED  INTERRUPTS  ! 
014C  7C05  El  VI 


014E  9E06  RET 
0150  END  SIGNAL 
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(£150  SET  PREEMPT  PROCEDURE 

I  *99999999999999  9999999999999 

*  SETS  PREEMPT  INTERRUPT  ON* 

*  TARGET  TP.  CALLED  BT  TC  * 

*  ADVANCE.  "  * 

9999999999999999999999999999 

*  REGISTER  USE:  * 

*  PARAMETERS:  * 

*  ?1 rTARGET  VP  ID  (INPUT)  * 

*  LOCAL  VARIABLES  * 

*  Rl:  VP_ INDEX  * 

9999999999999999999999999999  J 

ENTPV 

! *  NOTE:  DESIGNED  AS  SAFE  SECUENCE  SC  VFT  NEED 
NOT  BE  LOCKED.  ! 

!  CONVERT  VP  ID  TO  VP  INDEX  l 
ei5e  6112  LD  P.2T  EXT  VP  LIST  (El ' 

0152  021 0  ' 

!  TURN  ON  TGT  VP  PREEMPT  FLAG  ! 

0154  4D25  LD  VPT7v?.PREEMPT(R2) .  #ON 

0156  0018' 

015e  FFFF 

!  **  IF  TARGET  VP  NOT  LOCAL 

(  NOT  BOUND  TO  THIS  CPU  ) 

(IE.  IF  «CPU  SEG»CPU  IDOVFT.VP.FKYS  CPtr(Rl)J 
THEN  SEND  HARDWARE  PREEMPT  INTERRUPT  TO 
VPT.VP.CPU(Rl) .  **  ! 

015A  9E08  RET 

015C  ENr  SET  PREEMPT 


213 


015C  IDLE  PROCEDURE 

J  WMMW WWWWVWW W «« V  W 


*  LOADS  IDLE  D£R  ON  * 

*  CURRENT  VP.  CALLED  BY  * 

v  TC_GETW0*K.  * 

*  REGISTER  USE  * 

*  global  variable 

*  R13:  LCG  CPU  #  * 

*  ^14:  DER  » 

*  LOCAL  VARIABLES :  * 

*  R2 :  CURRENT  VP  * 

*  R3 :  TEMP  VAR  * 

*  R4 :  VPT .LOCK  ADDR  * 

*  R5:  TEMP  * 


ENTRr 


!  GET  LOGICAL  CPU  #  ! 


015C 

5F00 

CALL 

GET_CPU_N0  ! RETURNS: 

!  LOAD 

IDLE  DBR  ON  CURRENT  VP  ! 

45174 

6103 

LD 

R3 ,  PRDS . IDLE_VP 

0176 

0A10  ' 

0179 

6135 

LD 

R5,  VPT .VP . DER (R3  ) 

017A 

0010' 

017C 

6F25 

LD 

VPT.  VP.  DBF.  (R2),  P.5 

017E 

0010' 

!  TURN 

ON  CURRENT  VP'S  IDLE  FLAG  ! 

0180 

4D25 

LD 

VPT.Vp.IDLE_FLAG(R2)  ,  *ON 

eie2 

0015' 

0184 

FFFF 

!  SET 

VP  TO  READY  STATE  ! 

0186 

4D25 

LD 

VPT.VP.STATE(R2' ,  #P.EADY 

0198 

0014' 

016  A 

0001 

!  SCHEDULE  FIRST  ELIGIBLE  READY  VP 

018C 

5F00 

CALL 

GETWORX  !R13: LOGICAL  CPU  # 

018E 

0000' 

R14 :DPR  ! 

!  UNLOCK  VPT  ! 

0190 

4D08 

CLR  VPT. LOCK 

0192 

0000' 

!  UNMASK  VECTORED  INTERRUPTS  ! 

0194 

7C05 

SI 

VI 

eiye  9Eee 

0199 


RET 

END  IDLE 


0198 


0198  93F1 

019A  7cei 

019C  7604 
019E  0000' 
01A0  5F00 
01A2  0282' 


01A4  5F00 
0 1A6  02C8  ' 


0 1A8  A11D 

0 1 AA  61D2 
01  AC  0002' 

01AE  4D21 
0130  00  IE  ' 
01B2  FFFF 
0134  5S0b 
0136  01C4 ' 
0138  2100 
MlBA  0005 
01BC  76ei 
01BE  01BC  ' 
01C0  5F00 
01C2  A900 


SWAP  VDER  PROCEDURE 

»  W  wwvw  wwv 

*  LOADS  NFW  DiR  ON  * 

*  CURRENT  VP.  CALLED  3Y  * 

*  TC_GETWORK.  * 

«  *  m  « 9  « age  «jt  9  9  9  9  Jjt  9  *  w  9  *je * agca«c  9  «  « 

*  REGISTER  USE  * 

v  PARAMETERS  v 

*  Si:  NEW  D3R  (INPUTS  * 

*  GLOBAL  VARIABLES  * 

*  R13:  LOGICAL  CPU  *  * 

*  P.14:  D3R  * 

*  LOCAL  VARIABLES  * 

*  R2 :  CURRENT  VP  * 

*  R4 :  VPT.LOCK  ADDR  * 

WWW  vvv«y*V***V*****«**  1 

ENTR''r 

!  SAVE  NEW  D3R  ! 

PUSH  PP.15,  El 

!  MASK  INTERRUPTS  ! 

Cl  VI 
!  LOCK  7PT  ! 

LDA  R4 ,  VPT.LOCK 

CALL  SPI N_LOCK  !  (R4  :"VPT .LOCK )  ! 

!  NOTE:  RETURNS  WHEN  VPT  IS  LOCKED  BY  THIS  VP. 
!  GET  CPU  #  ! 

CALL  GET_C?U_N0  ! RETURNS: 

El:  CPU  # 

R2 :*  VP'S! 

LT  R13,  HI 

!  GST  CURRENT  VP  ! 

LD  R2 ,  VPT .RUNNI NG_LIS? ( 313 ) 

j  *  v  v  DEBUG  *  v  ¥  ! 

CP  VPT. VP. MSG  LIST ( R2 )  ,  *NIL 


IP  NE  !  MSG  WAITING  !  THEN 
LD  R0,  #S_N_A  !  SWAP  NCT  ALLOW  EE 
LDA  HI.  $  !PC! 

CALL  MONITOR 
FI 

!  *  *  END  DEBUG  *  *  ! 

!  SET  DBR  ! 
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V  *4  '  ’  "T-iP 


n 


r 


eiC4 

612E 

LD 

?14,  VFT . VP . DPR ( HP  ) 

01C6 

0/10' 

!  PEST 

ORE  NEW  DBR  ! 

e  ice 

y^r/ 

POP 

R0.  ORlb 

01CA 

6200 

CALI 

GET_DEP_ADDR  !  fR0:  IBP. 

eicc 

000 A. ' 

RETURNS 
(El:  ERR 

!  LOA1) 

NEW  DSP  ON  CURRENT  VP  ! 

01CE 

6221 

LD 

VPT . VP . DER ( R2  ^ ,  31 

01D0 

0010' 

!  TURN 

CPI  IDLE  FLAG  ! 

eiD2 

4D25 

IE 

VPT . VP . I DIE _ FLAG (R2 ' ,  #CFF 

01D4 

0016' 

01D6 

0000 

!  SET 

VP  TO  READY  STATE  ! 

01D6 

4D25 

LD 

V?T.VP.STAT2(R2)  ,  *REAEI 

01DA 

0014  ' 

01DC 

0001 

!  SCHEDULE  FIRST  ELGIELE  READ*  VP  ! 

eiDE 

bF00 

CALL 

G5TWORK  ! R13 : I OGICAL  CPU  * 

01  20 

0000  ' 

R14IDBR  ! 

!  UNLOCK  VPT  ! 

‘£10,2 

4D08 

CLR  VPT. LOCK 

0124 

0000 ' 

!  UNMASK  VECTORED  INTERRUPTS  ! 

0126 

7C05 

El 

VI 

0128 

ysee 

PET 

ZlfiA 

END  SWAP 

VEER 
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01EA 


PHYS  PREEMPT  HANDLER  PROCEDURE 

f  W  W9W*  W* jev  w*  W  WW>*  W  W  WW  W 


*  hardware  preempt  interrupt 

*  handier,  also  teste  pcr  * 

v  17 IRTL'Al  PREEMPT  INTERP.UPT  m 

m  FLAG  AND  INVOKES  INTERRUPT  * 

*  HANDIER  IP  PI AG  IS  SET.  * 

*  INVOKED  npON  EVERY  EXIT  FROM  * 

m  KERNEL.  KERNEL  FCW  MASKS  v 

*  NVI  INTERRUPTS  TO  PREVENT  m 

m  SIMULTANEOUS  PREEMPT  iNT-iRR .  * 

m  HANDLING.  * 

*  REGISTER  USE  * 

**  LOCAL  VARIABLES  * 

*  91:  FREEMPT  INT  FIAG  * 

*  R2 :  CUPRENT~VP  “  * 

*  GLOBAL  VARIABLES  * 

*  R13:LOGICAI  CPU  *  * 

*  P14:L1P  v 


WWW  VWVWV  V  WV»i*  WV  W  WW  WW  W  f 

ENTRY 

t  *  *  PREEMPT  HANDLER  *  *  ! 

!  SAVE  ALL  REGISTERS  ! 
eiEA  V53WP  S”B  HI 5,  # 32 

01EC  0020 

01  EE  1CF9  LDM  ORlb ,  SI.  #16 

01E0  651  fe?F 


]  SAVE  normal  stack  POINTER  (NS?)  ! 
01F2  7D6?  LDCTL  F 6 >  NSP 

01E4  93F6  PUSH  PHIS,  R6 

!  GET  CPU  ft  ! 

01F6  6F00  CALL  C-ET  CPU  NO  'RETURNS: 

Zli'3  02C8 ' 

His  CPU  * 

R2:#  VP  'S  r 

01FA  A11D  LD  R13,  HI 

!  MASK  INTERRUPTS  ! 

eirc  ?cei  pi  vi 

!  LOCK  VPT  ! 

01FE  7604  LDA  R4.  VPT. LOCK 

0200  0000' 

0202  5F00  CALL  SPIN  LOCK 

0204  0282' 

! RETURNS  WHEN  VPT  IS  LOCKED! 

!  SET  VSR  ! 

0206  61D2  ID  R2,  VPT. RUNNING  LIST (R12 5 
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0209  0002' 

020A  6123  LD  R 14 •  VPT . VP . DER ( R2 ) 

020C  <5010 ' 

1  PUT  CURRENT  PROCESS  IN  READY  ST!  TE  ! 

0 2eE  4E25  ID  V PT . VP . ST AT E ( R2 ),  HEAD Y 

55210  0014  / 

0212  0001 

0214  bF00  CALL  GET  YORK  !R13:L0G  CPU  * 

0216  0000' 

R14  :LER  ! 

PREEMPT  RET: 

!  UNLOCK  VPT  ! 

0216  4D09  CL°  7?"'  .LOCK 
021 A  0000' 

!  UNMASK  VECTORED  INTERRUPTS  ! 

021 C  7C05  El  VI 

KERNEL  EXIT: 

i  UNMASK  VIRTUAL  PREEMPTS  ***  ! 

!  **  note:  SAFE  SEQUENCE  AND  DOES  NOT  REQUIRE 
VPT  TO  BE  LOCKED.  **  ! 


!  GET  CURRENT  VP  ! 


021 E 

610D 

LD 

R13,  PP.DS  .IOG_CPU_  ID 

0220 

0A0C  ' 

0222 

61B2 

LD 

R2, 

VPT.3UNNING_LIS?(R13> 

0224 

0002' 

; 

TEST 

PREEMPT  INTERRUPT  FLAG  ! 

0226 

4B21 

CP 

VPT .VP .PREEMPT ( R2 ^  ,  *CN 

0228 

0018' 

022A 

FFFF 

022C 

SE0E 

IF 

EQ 

!  PREEMPT  FLAG  IS  ON  !  THEN 

022E 

0240  ' 

!  RESET  PREEMPT  FLAG  ! 

0230 

4D25 

ID 

V?T.VP.?PEEMFT(H2'  ,  *OFF 

0232 

0019' 

0234 

0000 

!  SIMULATE  VIRTUAL  PREEMPT  INTERRUPT 

0236 

2101 

LD 

R 1 ,  a  V 

0238 

00  00 

R2,  VPT. VIRT_INT_VSC (81 ) 

023A 

6112 

LD 

023C 

000C  ' 

023E 

1S28 

JP 

3^2 

!  NOTE:  THIS  JUMP  TO  TRAFFIC  CONTROL 
IS  USED  ONLY  IN  THE  CASE  OF  A  PREEMPT  INTERRUPT, 
AND  SIMULATES  A  HARDWARE  INTERRUPT.  ! 

!  END  VIRTUAL  PREEMPT  HANDLER  ***  ! 

FI 
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!  NOTE:  SINCE  A  HDVE  INTERRUPT  DOES  NOT  EXI 
THROUGH  THE  GATE,  THOSE  FUNCTIONS  PF.OVI 
3Y  A  GATE  EXIT  TO  HANDLE  PREEMPTS  MUS 
PROVIDED  HERE  ALSO.  ! 

!  RESTORE  NS?  ! 

02 40  y^Fb  POP  Rb,  0R15 

0242  7DbF  LDCTL  NSP,  Rb 

!  RESTORE  ALL  REGS TEES  ! 

0244  1CF1  LDM  Rl,  0Rlb,  *1« 

024b  0145F 

0248  010F  ADD  R15,  *32 

024 A  0020 

!  EXECUTE  HARDWARE  INTERRUPT  RETURN  ! 

024C  7R0I0  IRET 

024E  END  PKYS  PREEMPT  HANDLER 


e-tc-i  e  < 


024E 


RUNNING  *P  PROCEDURE 

*  CALLED  BY  TRAFFIC  CONTROL.  * 

*  RETURNS  VP  ID.  RESULT  IS  VALID* 

*  ONLY  WHILB"APT  IS  LOCKED.  v 

¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥ 

*  REGISTER  USE  * 

'*  PARAMETERS  * 

*  Rls  EX?  VP  IE  ( RETURNEE )  * 

*  R3 :  LOG'CPU  *  (RETURNEE)  * 

*  LOCAL  VARIABLES  * 

*  R2:  VF  INDEX  * 

¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥ J 
SN?RV 

!  MASK  INTERRUPTS  ! 

024E  7C01  01  VI 

!  LOCK  VPT  ! 

025e  7604  LEA  H4.  VPT. LOCK 

0252  0000' 

0254  5F00  CALI  SPIN  LOCK  !  (R4  :"VPT .  LOCK )  ! 

0256  0282  ' 

!  NOTE:  RETURNS  WHEN  VPT  IS  LOCKEr  BY  THIS  VP  ! 
!  GET  LOGICAL  CPU  *  ! 

0258  5F00  CALL  GET  CPU  NO  ! RETURNS: 

025A  02C8  ' 

Rl:  CPU  * 

R2  :#  Vp'S! 

025C  A113  ID  R3 ,  Rl 

025E  6132  LD  R2,  VPT. RUNNING  LIST(R3) 

0260  0002' 

!  CONVERT  VP  INEEX  TO  V?  ID  ! 

0262  6121  ID  P.lT  7PT.VP.EXT3IE(R2) 

0264  0020' 

|  ¥  ¥  ¥  DEBUG  ¥  ¥  ¥  I 
0265  0B01  CP  Rl,  4NIL 

0266  FFFF 

026 A  5E0E  IF  EQ  !  KERNEL  PROC  !  TEEN 

026C  027A' 

026E  2100  LD  R0,  #V_I_E  !  VP  INDEX  ERROR  * 

0270  0006 

0272  7601  LDA  Rl,  $ 

0274  0272' 

0276  5F00  CALL  MONITOR 

0278  A900 

FI 

!  *  *  END  DEBUG  *  *  ! 

!  UNLOCK  VPT  ! 

027 A  4D0e  CLR  VPT. LOCK 

027C  0000' 

!  UNMASK  VECTORED  INTERRUPTS  ! 

027E  7C05  El  VI 

0280  9E08  RET 

0282  END  RUNNING  VP 
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0282 


SPIN  LOCK  PROCEDURE 

*  USES  SPIN  LOCK  MECh.  * 

*  LOCKS  UNLOCKED  DATA  * 

*  STRUCTURE  (POINTED  TC  * 

*  BY  INPUT  PARAMETER).  * 

WV  VV  «  «<¥¥*¥*■  J.«M  *¥  V  ¥  W  W 

'•REGISTER  USE  * 

*  parameters  * 

*  P4 :  LOCK  ADDR  ( INPUT ) * 

¥****¥*¥¥¥*¥***¥*¥¥¥>!•***¥  I 

ENTRY 

!  NOTE:  SINCE  ON  Lr  ONE  PROCESSOR  CURRENTS 
IN  S  t STEM .  LOCK  NOT  NECESSARY.  **  ! 
•  *  *  *  DEBUG  *  *  *  ! 

0282  0D41  CP  GR4 ,  »0FF 

0284  0000 

0286  5S06  IF  Ni  !  NOT  UNLOCKED  !  THEN 

0288  0296 ' 

028 A  2100  LD  R0,  *U  L  !  UNAUTHORIZED  LOCK  ! 

028C  0000 

026S  7601  LDA  Rl,  S 

0290  028E  * 

0292  5F00  CALL  MONITOR 

0294  A900 

FI 

!  *  *  END  DEBUG  *  *  l 
TEST  LOCK: 

!  DO  WHILE  STRUCTURE  LOCKED  ! 

0296  0D46  TSET  0R4 

0298  E5FE  JP  vl,  TEST  LOCK 

7  v*  N0TE  sbs  PLZ/ASM  MANUAL 
FOR  RESTRICTIONS  ON 
USE  OF  TSET.  **  ! 

029 A  9S08  RET 

029C  END  SPIN  LOCK 
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029C 


ITC_S5T_S 5G_PTR  PROCEDURE 

V  GETS  BASE  ADDRESS  OF  SEGMENT  v 
*  INDICATED.  * 

^  w  »  « m  «* m  w  v  w  w  « *  w  x»  *  v  w  *  *  m  *  »*«  w  v  *  *  w 


V 

REGISTER  USE: 

V 

* 

R0  :SLG  BASE  ADDRESS (RET  > 

V 

* 

Rl : SEG  N®  (INPUT) 

* 

V 

R2:RUNNING  VP  (LOCAL) 

* 

R3 : DBR  VALOE  (LOCAL) 

a* 

n 

R4 :  VFT .LOCK 

* 

V 

R13:LCGICAL  CPU  # 

029  C  93F1 

029E  7C01 

02A0  7604 
02A2  00e0' 
02A4  5F00 
02A6  0292  ' 

02AB  5F0fc 
02AA  02C8  ' 


02AC  A11D 

02AE  97F1 
02B0  61D2 
02B2  0002' 
02B4  6123 
02B6  0010' 

0228  4D08 
02BA  0000' 

02BC  7C0b 
02BE  1900 
02C0  0004 
02C2  7130 
02C4  0100 


ENTRY 

!  SAVE  SEGMENT  #  I 
PUSH  ORIS,  HI 

!  MASK  INTERRUPTS  ! 

DI  VI 

!  LOCK  VPT  ! 

IDA  P4t7PT  .LOCK 

CALI  SPIN_L0CK  f R4 : "VPT. LOCK  ! 

!  GET  CPU  #  ! 

CALL  G?T_CPU_NO  ! RETURNS : 

Rl:  CPU  n 
P.2:#  VP'S! 

LD  P13,  Rl 

!  RESTORE  SEGMENT  *  ! 

POP  Rl,  OR 15 

LD  R2 , VPT . RUNN ING_L 1ST (R13 ) 

ID  R3 , VPT . VP .DBR ( R2 ) 

!  UNLOCK  VPT  ! 

CLR  VPT. LOCK 

!  UNMASK  VECTORED  INTERRUPTS  ! 

El  VI 

MULT  RR0 , #4 

LD  Re,R3(Rl) 


02C6  9E08  RET 

02C8  END  ITC  GET  SEG  PTR 
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GST  CPU  NO  PROCEDURE 

*  FIND  CURRENT  CPU  NO  * 

^  CALLED  Bv  DIST  MMGR  * 

*  and  mm  * 

vw  w  w  ww 
»  RETURNS  v 

*  Rl:  CPU  NO  * 

»  R2:  #  OF  VP'S  * 

IW*M»*¥MWWV¥»  I 


ENTRY 


02C8 

6101 

ID 

Rl, 

PRDS .I0G_CPU_ID 

02CA 

0A0C  ' 

02CC 

6102 

LD 

R2, 

PRDs . VP_NR 

02CE 

0A0S  ' 

02D0 

9E08 

RET 

02D2 

END  GET_CPU 

_N0 

02D2 

K 

LOCK 

PROCEDURE 

t  vww wvwww ww&ww v? 


*  STUD  FOR  WAIT  LOCK  * 
wvwvvmviiiiKvmoiivvvv** 

*  R4:"10CK  (INPJT)  * 

VW9V  ww*  WWW  1)1  WWW *j»  ! 

ENTRY 

02D2  5F00  CALL  SPIN  LOCK 

02D4  0282' 

02D6  9E08  PET 

02D8  END  fC  LOCX 


02D6  K_UNLOCK  PROCEDURE 

^  STUB  FOR  WAIT  UNLOCK  * 

J*** »M  W W 

V  R4:~L0CK  (INPUT)  * 

VM VW WWW 9VVWV MV MMM VW V  W  J 

ENTR  Y 

02D8  0D48  CLP  PP.4 

02DA  9E08  RET 

02DC  END  K_UNL0CK 

END  INNER  TRAFFIC  CONTROL 
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